str, num, newLen ... always being nitpicked!

[Stuart Goss]

Hi there,

I *keep* on having this problem with the nitpicking company:

when I call my variables (or arguments)
"str", "num" or "newLen"
instead of
"string", "number" or "newLength"
I am nitpicked and told I could use some extra letters as they come for free.

Actually, I'm always worried about my lines of code getting too long.
And personally, when I see "num" my head tells me "number".
Same with similar abbreviations.

So what's so bad about using the abbreviations?

Stuart

[Pauline McNamara]

Hi Stuart,

It can be a really subjective thing - you've probably noticed that some nitpickers are stricter on variable names than than the instructor's solutions.

I look at it from a readabiliy perspective. And for me, readability goes hand in hand with cognitive load, our brains' "RAM". That is, the more the person reading the code has to "hold on" to what exactly a variable name represents (num means number, len means lentils, oops, I mean length), the less room there is for figuring out other, more important stuff, like how the overall program works. Our brains only have so much "RAM" to work with up there.


And personally, when I see "num" my head tells me "number".

See the extra cognitive step in there? Your head has to tell you. Sure it's a trivial little thing in this case, but when you're working on a more complicated program, or when you're debugging any program in the middle of the night, your brain wants as much of its cognitive potential as possible for figuring out the big stuff.

It might be clear to you, but it has to clear for someone else too. Explicit variable names go that extra step to make sure it's clear, even if at the subconscious level. That's what readability means to me.


Actually, I'm always worried about my lines of code getting too long.

I'm not sure you need to worry about a few letters making your lines spill over. Is this a personal concern or is it related to the Style Guide's rule about Maximum Line Length?


Cheers,
Pauline


This just for discussion's sake (watch the feathers fly)... ...soooo, just what is an "s" in the problem your program is trying to solve?
[ January 16, 2006: Message edited by: Pauline McNamara ]

[Stuart Goss]

Thanks Pauline,

I'm not sure you need to worry about a few letters making your lines spill over. Is this a personal concern or is it related to the Style Guide's rule about Maximum Line Length?

I know the StyleGuide says 120 columns is ok, but I like to keep it to 80.
If I go over a biittt I don't mind (but the mail programmes sometimes do, but that is not so relevant in real time programming).

s: If it's an automatic variable (with pretty local scope: lifetime extends no more than one "page"/"screen"), then I wouldn't mind anybody (especially myself ) using this s as a String variable name.

What else could s be?

[Marilyn de Queiroz]

As Pauline said, readability is in the eye of the beholder. Different abbreviations may mean different things to different people. What seems obvious to you may not be obvious to another reader of your code. I think that 99% of the time, an extra couple of letters in an identifier is not going to make a difference in whether a line will exceed 80 (or 120) characters. On the other hand, there is a really big difference in readability between arlvn and aReallyLongVeriableName.

As far as 's' standing for String, generally a String is representing something, maybe a "name" or a "number" or ....
[ January 16, 2006: Message edited by: Marilyn de Queiroz ]

[Stuart Goss]

Hmmm,

thanks for the input.