|
The greater the scope, the bigger the name is as good a maxim as you'll get:
class Stuff
{
private int variable;
void doSomething (int thing)
{
Random rnd = new Random();
for (int i = 0; i< thing;i++)
{
int x = rnd.nextBoolean() ? i * 2 : -i;
this.variable += x;
}
}
}
God that looks silly 
veni bibi saltavi
|
|
|
|
|
Just curious as to why you can't actually spell out random instead of using "rnd". Are you really coding that fast and time is so crucial that you can't spell the word out? Just curious, Nagy.
|
|
|
|
|
Simply put, I can't be bothered to type the full word.
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: I can't be bothered to type the full word.
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
|
|
|
|
|
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
|
|
|
|
|
"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.
|
|
|
|
|
I use "meaningful" names for variables everywhere except for the "throw-away" variables in lambda expressions, for which I always use single char names.
You have just been Sharapova'd.
|
|
|
|
|
|
 Same here.
How do you know so much about swallows? Well, you have to know these things when you're a king, you know.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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
|
|
|
|
|
Meaningful names don't have to be long. We shun long names where I work.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
