|
well, "random" is long, longer than "rand" or "rnd" for example. So elementIterator or eleIter or elIt? In a couple of month I'd forget what "elIt" may be, but the complete form is way too long.
It really depends and there is nothing exact...
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.
|
|
|
|
|
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
|
|
|
|
|
Slacker007 wrote: My personal opinion is that you should use meaningful names.
You use what is appropriate.
I do not need a 255-char "meaningfull" variable name if it is only used twice. It makes stuff harder to read.
I do not need a "r" variable that is used everywhere.
If the scope is limited, limit the name. Large scopes should have longer names, for clarity.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Good points.
Question, do you work by yourself, or in a team (a shop). Will there ever be a scenario where 8 months down the road someone else has to maintain your most excellent code?
|
|
|
|
|
I have worked in brownfields for over 15 years. I know that code should be readable. In that time I've seen unreadable code due to insanely long names, and I've seen unreadable code due to one-letter naming.
You do not choose either, you use what is readable.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: you use what is readable.
I agree. I, and our team, use what is readable. 
|
|
|
|
|
Context rules in variable names.
"Hey You" is perfectly acceptable in some circumstances (in addition to song titles), while your full name is required in others (even "Slacker007" is allowed, in suspicious websites).
|
|
|
|
|
|
It kind off depends?
If you have a nested for loop you could use i and j eg as is often done, but I have seen (and have done  ) situations that ended up in having i, j, k, l, ... or worse i, ii, iii etc...
I use simple one character variables or short abbreviations only when it remains clear. for single or double for loops that is i and j. If it becomes more complicated I use more descriptive naming.
For StreamWriter I usually use a short name if it is in a "write" method eg. If I would use it throughout the class or if I would use multipe instances, naming would be more descriptive.
shorter names tend to make it, for me at least, more easy to read and understand.
|
|
|
|
|
Depends on payment.
If (paid more, or also paid zero (as in open source)) {
Use meaningful names
} else {
Use cryptic names as a means of self-obfuscation
}
|
|
|
|
|
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
|
|
|
|
|
Explains a lot about SAP.
|
|
|
|
|
No thank you. 
|
|
|
|
|
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
|
|
|
|
|
In the very old times when storage was expensive, you had to shorten the variable names to the extreme levels where "user" was shortened to "usr".
Today it's just pointless.
There's no point to use overly short variable names outside the fact that you are used to it.
You should of course use a name as short as possible, what random stands for would in most cases be obvious from the context of the scope, and only in the few cases where it isn't, or where you need more than one random variable you would need to specify RandomTemp or RandomPostCode.
<edit>I should probably add that I find it ok to use abbreviations like sw for StreamWriter when they are standardized, but as soon as there is room for ambiguity I spell them out.</edit>
modified 18-Sep-15 8:00am.
|
|
|
|
|
In loops, "i" and "k" are my gold standard. I'm more verbose in any other place, but "random" might be just the first version. "Self-explanatory" names are subject to refactoring...
|
|
|
|
|
TRhank got me thinking the first time I had to code a pointer I used the name pointy (which was released), I tend to use i, j, k for loops and short names like Cars[] for array of Car types (don't ask!) I tend to sw for Stream Writer, sr for Stream Reader. The only place I have had to follow a strict coding style was when I was at uni...
|
|
|
|
|
I use single character names for iterators, even when nested provided the content of all loops is small enough to see easily:
for (int i = 0; ...
for (int j = 0; ...
...And I use single characters where they are appropriate: "XCoord" and "YCoord" don't add anything useful to "X" and "Y".
And I'll use two or three char names for "disposables" like a streamwriter where I'll create, write, close, and dispose in three or for lines, or for a file dialog:
OpenFileDialog ofd = new OpenFileDialog();
if (ofd.ShowDialog() == DialogResult.OK)
{
string filepath = ofd.FileName;
...
}The rest of the time, it's "sensible", "meaningful" names all the way!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Slacker007 wrote: My personal opinion is that you should use meaningful names.
I concur. I've never heard any developer complain that someone's code was too clear. 
/ravi
|
|
|
|
|
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. 
Slacker007 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 using statement, so sw is 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.
|
|
|
|
|
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
|
|
|
|
|
|
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 ) 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
