Best Programming Advice Ever.
-
I just settle for calling them tmpStr tmpInt etc so I know. Tend not to use them at all unless I have to
My first thought was putting that in context with the idea of a 1000+ line function and thinking: well that's just gonna piss him off all over again. Might as well just call it thisVariableHasMoreThan1Letter or singleLetterVariablesSuck. But as a response to my point it does make sense. I do that, too, in most such situations. But not all.
-
Just do what apple do. Create a platform...IPOD/IPHONE They only change 3 things every 6 months..(Email forwarding (cmon we all know that took a day to write))..have a big macworld announcement and the starving clients will praise you forever. :) 6 bugs /year...think thats a programmers best average? :)
-
... in the right circumstances. Pretty much being that the variable is in a very short scope and is basically a tmp variable, where the name is not important.
Don't let my name fool you. That's my job.
At the place where I used to work the guy who was there before me made *every* variable a global (this is in VB6) and would start with the name AAA and work his way upwards :-s
-
At the place where I used to work the guy who was there before me made *every* variable a global (this is in VB6) and would start with the name AAA and work his way upwards :-s
-
I just settle for calling them tmpStr tmpInt etc so I know. Tend not to use them at all unless I have to
KungFuCoder wrote:
I just settle for calling them tmpStr tmpInt etc so I know.
It's better than nothing I suppose, unless you're using a statically typed language, in which case it's completely useless (e.g. "int tmpInt" is redundant and a waste of brain/finger time).
-
That point is irrelevant. I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. Makes the code fairly hard to understand if all the tmp variables happen to be one letter, trust me.
Sincerely Yours, Brian Hart
Brian Hart wrote:
That point is irrelevant. I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. Makes the code fairly hard to understand if all the tmp variables happen to be one letter, trust me.
I'll tell you what makes the code fairly hard to understand: having a single function which is thousands of lines long. This is idiotic and completely unnecessary - we've had procedures and functions and other abstractions since before colour TV, and their main use is to prevent thousand line functions from ever existing. IMO, tiny variable names are okay if you have quite short functions, which you really should anyway.
-
... in the right circumstances. Pretty much being that the variable is in a very short scope and is basically a tmp variable, where the name is not important.
Don't let my name fool you. That's my job.
It did have positive benefits back in the early days of COBOL, punched cards, and things like that. Anything that saved memory was a good thing. You know, like 2-digit years.... hmmm... Yes, I have attempted to maintain programs from that era. Two-letter variable names and labels, many hundreds of gotos, even more hundred alter-gotos. Having done so, let me add something to that original advice. 2) If you use 1 or 2 letter variable names, do not leave your name in the comments at the top of the code to say what you did. 2a) Especially if one of the programmers who will read it, a few decades later, is your own daughter. She DOES know where you live.
-
That point is irrelevant. I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. Makes the code fairly hard to understand if all the tmp variables happen to be one letter, trust me.
Sincerely Yours, Brian Hart
I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. There is nothing wrong, IMHO, with using trivial variable names in cases where the scope of the variable is short and its meaning can be entirely gleaned from context. A classic example:
For I As Integer = 1 To 40
Item.Dat(I) = 0
NextWould using any name other than "I" make things clearer? Of how about something like:
Dim st As String
st = GetSomeData();
If Not String.IsNullOrEmpty(st) Then
DoSomethingWith(st)
EndifWould any name other than "st" be more helpful?
-
Just do what apple do. Create a platform...IPOD/IPHONE They only change 3 things every 6 months..(Email forwarding (cmon we all know that took a day to write))..have a big macworld announcement and the starving clients will praise you forever. :) 6 bugs /year...think thats a programmers best average? :)
clearbrian1 wrote:
6 bugs /year...think thats a programmers best average?
Jeez, if I only create six bugs per hour, I'm having a helluva day. :sigh:
Someone's gotta be the last to know, but why is it always me?
-
-
clearbrian1 wrote:
6 bugs /year...think thats a programmers best average?
Jeez, if I only create six bugs per hour, I'm having a helluva day. :sigh:
Someone's gotta be the last to know, but why is it always me?
goodideadave wrote:
Jeez, if I only create six bugs per hour, I'm having a helluva day.
Per hour, you are probably programming too fast. Are you counting failed compiles/syntax type errors? I don't consider that a bug.
John
-
goodideadave wrote:
Jeez, if I only create six bugs per hour, I'm having a helluva day.
Per hour, you are probably programming too fast. Are you counting failed compiles/syntax type errors? I don't consider that a bug.
John
Wow, I have never been accused of coding too fast before, usually it's just the opposite...
Someone's gotta be the last to know, but why is it always me?
-
It did have positive benefits back in the early days of COBOL, punched cards, and things like that. Anything that saved memory was a good thing. You know, like 2-digit years.... hmmm... Yes, I have attempted to maintain programs from that era. Two-letter variable names and labels, many hundreds of gotos, even more hundred alter-gotos. Having done so, let me add something to that original advice. 2) If you use 1 or 2 letter variable names, do not leave your name in the comments at the top of the code to say what you did. 2a) Especially if one of the programmers who will read it, a few decades later, is your own daughter. She DOES know where you live.
-
Dave Parker wrote:
At the place where I used to work the guy who was there before me made *every* variable a global (this is in VB6) and would start with the name AAA and work his way upwards :-s
Now that's a master coder.
-
KungFuCoder wrote:
I just settle for calling them tmpStr tmpInt etc so I know.
It's better than nothing I suppose, unless you're using a statically typed language, in which case it's completely useless (e.g. "int tmpInt" is redundant and a waste of brain/finger time).
In my very short scope example, most likely so, but not for the reason you say. The fact that the compiler will catch a mistake does not make it easier to read and understand. A short scope of 10 lines or less means we don't really need to care what it is. But if you are evaluating 20 different boolean results over the course of a 100+ line function, you might not want to spend a lot of time thinking of 20 meaningful but distinct names. tmpBool would do just fine.
Don't let my name fool you. That's my job.
-
I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. There is nothing wrong, IMHO, with using trivial variable names in cases where the scope of the variable is short and its meaning can be entirely gleaned from context. A classic example:
For I As Integer = 1 To 40
Item.Dat(I) = 0
NextWould using any name other than "I" make things clearer? Of how about something like:
Dim st As String
st = GetSomeData();
If Not String.IsNullOrEmpty(st) Then
DoSomethingWith(st)
EndifWould any name other than "st" be more helpful?
-
I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. There is nothing wrong, IMHO, with using trivial variable names in cases where the scope of the variable is short and its meaning can be entirely gleaned from context. A classic example:
For I As Integer = 1 To 40
Item.Dat(I) = 0
NextWould using any name other than "I" make things clearer? Of how about something like:
Dim st As String
st = GetSomeData();
If Not String.IsNullOrEmpty(st) Then
DoSomethingWith(st)
EndifWould any name other than "st" be more helpful?
Agreed. Certainly nothing wrong at all with "using trivial variable names in cases where the scope of the variable is short and its meaning can be entirely gleaned from context," as you say, and I quote.
Sincerely Yours, Brian Hart
-
Brian Hart wrote:
That point is irrelevant. I am talking about seeing this in high performance scientfic codes where a single function can be thousands of lines long. Makes the code fairly hard to understand if all the tmp variables happen to be one letter, trust me.
I'll tell you what makes the code fairly hard to understand: having a single function which is thousands of lines long. This is idiotic and completely unnecessary - we've had procedures and functions and other abstractions since before colour TV, and their main use is to prevent thousand line functions from ever existing. IMO, tiny variable names are okay if you have quite short functions, which you really should anyway.
"I'll tell you what makes the code fairly hard to understand: having a single function which is thousands of lines long." You can say that again!!! If at all possible I try not to have a function that goes over the number of lines that will fit comfortably in one screen of my programming editor.
Meddle not in the affairs of dragons, For you are crunchy, and good with mustard.
-
Thanks - had to laugh and print it out for my wall. The worst offenders of hard to maintain seem to be people who aren't programming in old dusty code where good practice (comments, well named variables) are lifelines to what was done and why. Or a consulting engineer who refused to comment code because he said comments were always wrong - out of date - see the code! And wrote frightfully elegant code that was very difficult to figure out.
