Coding style questions -- variables

[Luke_Drillbrain]

My coding background is in MS Visual BASIC 6.  Most of the VB books I used, including Microsoft's guidelines in MSDN advocated declaring all variables at the beginning of every sub with commenting explaining what each was for.  The programming language did not make that mandatory; code would run otherwise, but most of my VB books strongly recommended including a variable declaration section at the top of your sub. 

So that's how I did it.  However, in the Eric Matthes Python book that I'm working my way through, I notice that he declares variables as needed, and it would appear that it's not separate from putting in its first value.  Is this just how Matthes does it or is that a stylistic standard of Python.  I have no intention of coding professionally, but I do intend to contribute to the Linux GNU freeware community.  If there's a good reason for me to alter my coding style because of going to a different language, I could certainly manage to do that. 

It would also appear that Matthes does not use Hungarian-style variables.  That was another thing hammered in by most VB standards.  The idea was to always include a prefix that tells the data type.  For example:

Dim intLoop as Integer 
Dim strName as String

You could even include the scope:

Dim l_intLoop as Integer '<==== Local variable
Dim m_intLoop as Integer '<=== modular level variable
Dim g_intLoop as Integer '<==== global variable (though globals were generally discouraged)

I could stick with Hungarian if there's enough of an advantage to doing so.  On the other hand, if it would be an advantage to working with other GNU freeware authors, I could junk it.  The code, of course, runs regardless of how you name your variables. 

Ultimately, I want my code to always be clean, easy to read, and commented, so whatever serves that end best is what I want to do.

[Mekire]

I could stick with Hungarian if there's enough of an advantage to doing so. 

Hungarian is not encouraged.

There is the somewhat informal Zen of Python viewable via typing import this in the interpreter.
More formally there is pep8 which is the official style guide:
https://www.python.org/dev/peps/pep-0008/  

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

[Larz60+]

I think coding style is something you 'just pick up' as a matter of course.
That being said, in all object oriented languages, where a variable is declared
is related to it's scope.
In a python method, or function (sub in VB, in python, function if outside of a class, method if within),
if the variable is to be used for the entire method, it should be declared at the top, if it is only being used
within a for or while loop, declare it within. There are rules in python, the most famous is PEP8, which
you can read here: https://www.python.org/dev/peps/pep-0008/
If the variable will be shared between methods, (within a class), it should be declared in the __init__ method, and be preceeded
by self., or passed as an argument.


If it is to be shared between functions outside of a class, it should be declared in the first function that needs
access, and then passed as an argument to the other functions (that require it's use).

Hope that's helpful

[llanitedave]

@Luke_Drillbrain:

Remember Python is dynamically typed, so assigning a type to a variable name is rarely a good idea.  Your int can easily turn into a float, or a string somewhere in the program.  Use informative names for your variables, but not potentially misleading ones.  Good comments are also important, but don't overdo it so much as to make the code redundant.  The best place for explanatory comments in your code is in the docstrings, which will make for some interesting reading once you entered the documentation for them.

[volcano63]

@Luke_Drillbrain:
Your int can easily turn into a float, or a string somewhere in the program. 

This is not actually right. Part of the "dynamic" means that re-assignment of a variable name - which is not a permanent container, like in compiled languages - sets that variable as a reference to a different object. 

Little demonstration

In [1]: a = 1

In [2]: id(a)
Out[2]: 10055552

In [3]: a = 2

In [4]: id(a)
Out[4]: 10055584

In [5]: a = '1'

In [6]: id(a)
Out[6]: 140614774162408

Variable name is simply an alias to the variable object  - that's why compiled-language style declarations in Python are pointless.

[llanitedave]

@llanitedave
This is not actually right. Part of the "dynamic" means that re-assignment of a variable name - which is not a permanent container, like in compiled languages - sets that variable as a reference to a different object.

That's true, it would have been more accurate to phrase it as repointing the variable name to different objects.  But to the user, the effect is the same, I think.  He'll see "a" consisting of an integer at some point in the program, but later he might reference "a" and find a string.  It's a different object, the variable name hasn't changed, but the object it refers to has.  What the user sees is a change in the association between variable name and data type, and regardless of the internals of the program, he's going to look at that "a =" symbol and read it as "a equals" a new object.  When it "equals" something else later, the impression will always be that the variable has changed, even though, technically speaking, it really hasn't.

[volcano63]

@llanitedave
This is not actually right. Part of the "dynamic" means that re-assignment of a variable name - which is not a permanent container, like in compiled languages - sets that variable as a reference to a different object.

But to the user, the effect is the same, I think. 

It's not about the "effect", it's about understanding the language. Never hurts

[wavic]

It's about continuity.
When you write a code you have to follow the syntax rules if you want one to read your code without mentioning you relatives.

[volcano63]

It's about continuity.
When you write a code you have to follow the syntax rules if you want one to read your code without mentioning you relatives.

Speaking of continuity - I think you meant consistency ?! Usually after you define a variable, you stick with its type (unless it's None as initial value). Following syntax rules is necessary, but not sufficient condition to prevent profanity...

I know a guy who writes syntactically perfect code  - with average line length of 200 characters . Luckily, I am a civilized person 

[wavic]

Speaking of continuity - I think you meant consistency ?!

Don't know. The English is not my native language. :)
Just follow as close as you can PEP 8 :D