Question on variable naming style (i.e. r versus random)
-
r versus random. sw versus streamWriter, etc... Our shop only allows single character variable names on iterators, and even then, a meaningful iterator name is desired, especially if you have iterators in nested statements. You have to have something meaningful in the name. What's your take on this? My personal opinion is that you should use meaningful names. I should not have to go to the variable declaration to remember that r is random - you get the point.
The complexity of the variable name should reflect the size of its scope. The larger the scope, the more complex the name. And limit the scope as much as practical. Don't name a loop variable
ThisIsTheVariableThatIsUsedToIndexIntoTheArrayOfUsersWeReceivedFromThePreviousWebMethodCall. ;PSlacker007 wrote:
r versus random
In .net, you should probably have a private static field to hold an instance of a Random, that means the scope is the whole class, so a good meaningful name is appropriate -- I name mine
randy.Slacker007 wrote:
sw versus streamWriter
I generally use StreamWriters in a small
usingstatement, soswis appropriate. If the code in the scope becomes too large, then it should be broken into methods -- with a more complex name for the StreamWriter parameter. -
r versus random. sw versus streamWriter, etc... Our shop only allows single character variable names on iterators, and even then, a meaningful iterator name is desired, especially if you have iterators in nested statements. You have to have something meaningful in the name. What's your take on this? My personal opinion is that you should use meaningful names. I should not have to go to the variable declaration to remember that r is random - you get the point.
I'm in agreement with many of the replies. I use single letter iterators like i, j, & k for nested for-loops accessing a multi-dimensional array unless: a) scope is too large or b) it's helpful know what the dimensions represent. I personally prefer "reasonably" sized var names (entirely subjective I know) that make it clear what it represents three pages down and 14 months later. I do also follow the guideline, "when in Rome...". If I'm modifying someone else's code, I will adopt their style of brace positioning, commenting, and var naming conventions (e.g. if they use Hungarian notation). The overarching principles for me are readability and clarity later on if I need to augment or fix it.
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
-
I'm in agreement with many of the replies. I use single letter iterators like i, j, & k for nested for-loops accessing a multi-dimensional array unless: a) scope is too large or b) it's helpful know what the dimensions represent. I personally prefer "reasonably" sized var names (entirely subjective I know) that make it clear what it represents three pages down and 14 months later. I do also follow the guideline, "when in Rome...". If I'm modifying someone else's code, I will adopt their style of brace positioning, commenting, and var naming conventions (e.g. if they use Hungarian notation). The overarching principles for me are readability and clarity later on if I need to augment or fix it.
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
:thumbsup:
-
r versus random. sw versus streamWriter, etc... Our shop only allows single character variable names on iterators, and even then, a meaningful iterator name is desired, especially if you have iterators in nested statements. You have to have something meaningful in the name. What's your take on this? My personal opinion is that you should use meaningful names. I should not have to go to the variable declaration to remember that r is random - you get the point.
For iterators I most always use single character names, but on occasion I have been know to use unrelatable, long, bizarre and ridiculous names just to confound, annoy, bemuse and jeer at those who may have to maintain or alter my code long after my departure (be it due to retirement, death, or lottery windfall ) :-D
-
Nagy Vilmos wrote:
I can't be bothered to type the full word.
:-D Fair enough.
No, not fair enough. That's a cop-out. Meaningful variable names should be used everywhere. Programmers who claim that it's too much typing need to either take a typing lesson or hope that I never need to maintain their code.
Gus Gustafson
-
Sometimes even a variable name like random may not be enough. What does random stand for - Random temperature value? Random foreign exchange value? Random number? Random forum post number? So use
rand consult the documentation anyway.Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
-
r versus random. sw versus streamWriter, etc... Our shop only allows single character variable names on iterators, and even then, a meaningful iterator name is desired, especially if you have iterators in nested statements. You have to have something meaningful in the name. What's your take on this? My personal opinion is that you should use meaningful names. I should not have to go to the variable declaration to remember that r is random - you get the point.
Single letter names are ok if the scope of the variable fits in a few lines, so that you can see the definition along with all the uses. Iterators are (usually) an example of this rule. For people who have been programming long enough, i,j, and k naturally name the first, second, and third array dimensions. It's an ancient FORTRAN thing that lives on in the modern world, the way foo, bar, and blah from LISP 1.5 do). Like all coding rules, this one has to be used with judgement. If using single-letter variable names is the alternative to 150-character long statements, which adds the most complexity.
-
My first coding job was on SAP, and I grew to to like the abbreviated table and column names, where most table names were always four characters, and most column names five, e.g. BKPF-BELNR, or the Accounting Document Header table is BKPF and BELNR is Document Number. This way it's easy to remember after a few months, and there is no uncertainty like in using full names for e.g. underscores vs dashes, misspellings, spaces, etc.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
The SAP abbreviations probably make sense in the original German "book of accounts" -> "Buch der Konten"
Indeed they do, but while I worked on SAP, I found it very easy to pick up on the German terms used, and that made the naming pseudo-convention very easy to memorize and understand.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
It really depends. If I have to cycle through 3 levels of hierarchy i, j, k work better than any other name IMHO - even reading the code. Only for matrixes I use r and c to distinguish between rows and columns. n and m may also work... they ARE meaningful, but their meaning usually is very limited in scope so it's pointless to create long names for them.
Geek code v 3.12 { GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X } If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
One the biggest gripes I have with 'meaningful' names is their utility. What is the justification for having a 122 character variable name describing a boolean? Microsoft used to have such describing whether the screensaver was in blackout mode. There used to be a condition where the software would concatenate program.procedure.variable names and attempt to display the result in a 256 character namespace. If the concatenation exceeded the namespace limit, 'namespace_exceeded' would be displayed in place of the concatenation and debugging would be terminated. (Those were the days.)
The difficult may take time, the impossible a little longer.
-
No, not fair enough. That's a cop-out. Meaningful variable names should be used everywhere. Programmers who claim that it's too much typing need to either take a typing lesson or hope that I never need to maintain their code.
Gus Gustafson
If a block of cohesive code has several levels of nesting and a variable name is used in most of them, it is nice to be able to fit your block of code into a single screen so you can see everything without scrolling back and forth. I sometimes use small variable names for better readability. A comment can always clear up the intended use of the local variable.
-
If a block of cohesive code has several levels of nesting and a variable name is used in most of them, it is nice to be able to fit your block of code into a single screen so you can see everything without scrolling back and forth. I sometimes use small variable names for better readability. A comment can always clear up the intended use of the local variable.
"For better readability" is the key to your statement. Better readability is a prerequisite to better understanding. And better understanding is directly related to maintainability. Now consider for a moment that a maintainer is visiting your code for the first time. A couple of things: the maintainer may not recognize your algorithm and the maintainer may not know your coding style. So the easier it is for the maintainer to understand your code, the faster the error (why else a maintainer?) will be corrected. Meaningful variable names help. In short loops, I have no problem with small variable names, but only for integer indices, not for statements like foreach ( Address address in addresses ).... Once the form foreach ( Address a in addresses )... is allowed, bad things happen to understanding.
Gus Gustafson
-
"For better readability" is the key to your statement. Better readability is a prerequisite to better understanding. And better understanding is directly related to maintainability. Now consider for a moment that a maintainer is visiting your code for the first time. A couple of things: the maintainer may not recognize your algorithm and the maintainer may not know your coding style. So the easier it is for the maintainer to understand your code, the faster the error (why else a maintainer?) will be corrected. Meaningful variable names help. In short loops, I have no problem with small variable names, but only for integer indices, not for statements like foreach ( Address address in addresses ).... Once the form foreach ( Address a in addresses )... is allowed, bad things happen to understanding.
Gus Gustafson
"the maintainer may not recognize your algorithm and the maintainer may not know your coding style ... Meaningful variable names help." I have no disagreement with you that meaningful variable names help. Other helpful things might take priority in some corner cases. The scenario I thought of for shorter names was when you have many levels of nesting, hence lots of indentation outside the top of the code. In that scenario you either have unwieldly continuation lines that break up a SOC into many pieces that it won't fit on a screen without scrolling vertically, or you have long lines that require horizontal scrolling back and forth. Some comment lines, as I said, might be an alternative to the descriptiveness of long variable names and let you take in the block of code without your eye having to wander across broken lines or long lines. "Readability" can, of course, be different for different people. Maybe the majority of maintainers would side with you in all cases.
-
One the biggest gripes I have with 'meaningful' names is their utility. What is the justification for having a 122 character variable name describing a boolean? Microsoft used to have such describing whether the screensaver was in blackout mode. There used to be a condition where the software would concatenate program.procedure.variable names and attempt to display the result in a 256 character namespace. If the concatenation exceeded the namespace limit, 'namespace_exceeded' would be displayed in place of the concatenation and debugging would be terminated. (Those were the days.)
The difficult may take time, the impossible a little longer.
I use VS6. I know. Try using STL and be prepared for an avalanche of warnings... Maybe my definition of long is way shorter than 122 chars - that's just madness. 15 chars IS long and useful - also if the code is properly modularized and splitted in functions (or classes and methods, or libraries and procedures or whatever paradigm you are using) long names lose most of their significance: in a smaller sontext shorter names are just as useful.
Geek code v 3.12 { GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X } If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver