Variables, methods, objects

[tommeagher]

A small piece of feedback on PyCAR16 from @mjwebster:

I think it would help beginners a lot if you named variables in a way that makes it much easier to see what's a variable and what's not. For example, something like "vrow" or "vfilename" or "varfilename" or "var_row". Anything that sets them apart from everything else. It gets confusing when you have a variable named "writer' and then a command that includes "writer" and stuff like that.

I agree this is very confusing for newcomers to programming and to Python. Is there a way to simplify this, or to explain why we name the variable after the object created by the same-named method?

[scott2b]

Are there specific examples of confusing variable names? I am wary of the suggested approach which is dangerously close to Hungarian notation and I think teaches bad habits. If there are places in the example code where we are clobbering scoped modules or other objects, then those should definitely be fixed. I'd be okay with a convention such a using a 'my' prefix (my_writer, my_integer, etc.) as is often used in tutorial and instructive contexts, but again would be wary of teaching an approach that sanctions "variablizing" the name.

[mjwebster]

Here's an example from one of the scripts we did on Thursday:

writer = csv.writer(output_file,delimiter=',')

It's immensely confusing when "writer" is used in two different ways.

I don't understand why it would be bad to "variablize" names. "my_writer", "my_integer" etc would be useful. Why would this be a "bad habit"? Does it wreck the code somehow? Is it just that it requires extra typing?

You guys have to remember that you need to help beginners by lowering the bar a little bit. Yes, maybe it's easy for you to figure out what's a variable and what's not because you've been doing this for awhile. But it's not so easy for a beginner and based on the questions in last Thursday's class, I don't think I was the only one struggling with this. I've tried -- on my own -- to convert other people's sample scripts for my own use, and figuring out what's a variable and what's not was nearly impossible being a beginner at this. And, as with most things, cribbing from existing scripts is one of the best ways to get started learning just about anything. You had several people in last Thursday's class who said they were "repeaters" because they didn't grasp it the first time around. Maybe lowering the bar a little would help reduce that.

On Tue, Mar 15, 2016 at 4:18 PM, Scott Bradley notifications@github.com wrote:

Are there specific examples of confusing variable names? I am wary of the suggested approach which is dangerously close to Hungarian notation and I think teaches bad habits. If there are places in the example code where we are clobbering scoped modules or other objects, then those should definitely be fixed. I'd be okay with a convention such a using a 'my' prefix (my_writer, my_integer, etc.) as is often used in tutorial and instructive contexts, but again would be wary of teaching an approach that sanctions "variablizing" the name.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ireapps/pycar/issues/37#issuecomment-197024065

MaryJo Webster mjwebster71@gmail.com mjwebster71@gmail.com 651-491-6576 @MaryJoWebster

[richardsalex]

@mjwebster, I don't think it's an issue to carry those my_<whatever> conventions forward from the basics section into the first project. I appreciate the suggestion. I think @scott2b was just making the point that it has the capability to make the code less readable as things get more complicated, but this might not really matter for beginners who are just starting to grasp some of the concepts.

[scott2b]

I think in this example, my_writer = csv.writer ... would be fine. The use of "my" variables is something of a tutorial mainstay that I am ok with. The primary point of these in instruction or tutorial is to make it clear that the name is arbitrary (although we might have to explain that point up front.) What I maybe was not clear about is that I am wary of a "v" or "var" prefix notation or similar that introduces a vague concept of typification of variables. It's not really quite the same thing as Hungarian style prefixes, but is close enough in concept that I have a bit of a knee jerk reaction against it. It seems both non-pythonic and regarded as poor practice in the industry. This may be a case where it's worth the trade-off, but I think maybe just using "my_" variables would clarify enough without introducing bad habits.

[zufanka]

I agree that we should use variable names that are not confusing, however if I'm not mistaken, using "writer" for csv.writer is sort of a convention. So I think we also just might explain that while variable names are arbitrary, some are conventional: as one is going to come across the conventions further in the documentation and StackOverflow as well

Adriana

data journalist

+31-652245912 | 0F097E0F | @naberacka

On Tue, Mar 15, 2016 at 4:30 PM, Scott Bradley notifications@github.com wrote:

I think in this example, mywriter = csv.writer ... would be fine. The use of "my" variables is something of a tutorial mainstay that I am ok with. The primary point of these in instruction or tutorial is to make it clear that the name is arbitrary (although we might have to explain that point up front.) What I maybe was not clear about is that I am wary of a "v" or "var" prefix notation or similar that introduces a vague concept of typification of variables. It's not really quite the same thing as Hungarian style prefixes, but is close enough in concept that I have a bit of a knee jerk reaction against it. It seems both non-pythonic and regarded as poor practice in the industry. This may be a case where it's worth the trade-off, but I think maybe just using "my" variables would clarify enough without introducing bad habits.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ireapps/pycar/issues/37#issuecomment-197053569

[dannguyen]

I run into this problem quite frequently.

Even if writer is the convention when referring to some "writer" class, it is way too easy for a novice (and intermediate-level) to either conflate or mistake csv.writer with writer, when writer is a label that is completely arbitrary. I like using csv_writer if I feel like being explicit. Or, cw.

In the latter case, the variable name is not descriptive but this is one of those situations where a novice doesn't know better...in that if you use a verbose name for a variable that lives for 2 lines, you've greatly added onto the cognitive load. Novices need to get used to the fact that variables can be super simple, and, when seeing a super-simple variable, train yourself to focus on the next few lines.

[esagara]

This is actually one of the issues I noticed myself as we were going through the class. I spend a lot of time thinking about short, declarative variable names as I write my code so that it is self-documenting. I noticed that we had at times single or double letter variables, used reserved keywords for variables or used singular variable names for lists and dictionaries. Now some of this may be up to a matter of personal taste, but I do feel we could be a bit clearer in our variables.

In specific to the writer issue, here is how I normally approach that:

with open('example.csv','w') as outfile:
    output = csv.writer(outfile)
    output.writerows(rows)

When I code I also try to avoid using the same variable name as another function, object or whatever in python, even if it is something that requires namespacing such as csv.writer. For experienced coders its probably difficult for us to overwrite that function by accident (though I have done it), but it is confusing and can make the code harder to read.

I also think we should talk about making variable names consistent across projects. Each one right now contains the personal preferences of the individuals that created the project. This is fine to some extent but I wonder if developing a convention that spans projects will make it easier for new coders to digest.

The last point is that we are journalists; we can use our words to write short, declarative and self-documenting code - often I find quite a bit of joy in doing that. I personally would like to pass that on to new coders as they are learning Python.