Best Programming Advice Ever.
-
-
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.
