Variable Names
-
At my previous job - I was slogging through some legacy code in a financial application and came across a variable called Wayne_Gretsky and no one knew what it meant.
If you think that's bleak and cheerless, too bad. Reality doesn't owe us comfort. - Richard Dawkins
dexterama wrote:
Wayne_Gretsky
Probably a variable that could stick handle. See Wayne Gretzky[^]. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
-
for ( int i=0; i<10; i++)
{
for ( int eye=0; eye<10; eye++)
{
for (int aye=0; aye<10; aye++ )
{
}
}
}:laugh:
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) -
"Object" smells of Hungarian notation and elderberries. ;P I'm on a crusade at my workplace to stamp out Hungarian, so I'm just particularly sensitive to those sorts of things. Anyway, Hungarian aside, I use full and complete names. Pascal case or camel case depending on context. The only abbreviation I use is "Id".
I once used Hungarian notation in a project and another developer looked at it, rolled his eyes, and then sighed 'oh, Hungarian notation'. He was one of those self-aggrandizaing pricks who looked down on everyone else. He eventually went off and got a job at a prestigious company earning twice what I make. I hate that guy. :-D
-
I do it for a majority of things. The exception are objects that I ALWAYS abreviate the same way. tbl for table, cb for check box, cbo for combo box, vw for view and some others. These abreviations are not used for anything else and are always used when that type of object occurs. Otherwise, the more robust the variable name the better for reading the code. The easier it is to read, the less comments I have to make. The other exception is when I have to loop through something where the name of the iterator doesn't matter, then it is 'j'.
same here.
It used to be what you know that got you ahead, then it was who you know, now its what you know about who you know that gets you ahead. Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
-
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
MehGerbil wrote:
It may get a wee bit tedious ... I find it less confusing.
IMHO, clarity wins over tedium. The coding standards where I work require explicitly specified table and field names. As a result, devs have no problem deciphering our schema. And that's a HUGE win. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
i, then j, then k, then l, then whatTheFrickAmIDoingNestingLoopsThisDeep.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
MehGerbil wrote:
Does anyone else do this...
I do. I've never been a fan of shortened names (e.g., no vowels, abbreviated abbreviations), especially when there's no reason.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
I do too. Because I like to think about the task and not only what kind of value that damn variable was. One colleague does not. It's a mess.
regards Torsten When I'm not working
-
dexterama wrote:
Wayne_Gretsky
Probably a variable that could stick handle. See Wayne Gretzky[^]. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
It is hard replying to the correct message. :-D
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
I generally like descriptive names, one developer that I worked with use to abbreviate them so much it was more of a decipher his variable names before you could work out his code.
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
-
OriginalGriff wrote:
whatTheFrickAmIDoingNestingLoopsThisDeep
Shouldn't it be whatTheElephantAmIDoingNestingLoopsThisDeep?
No, my coding standards specifically ban swear words.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
I generally like descriptive names, one developer that I worked with use to abbreviate them so much it was more of a decipher his variable names before you could work out his code.
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
...that comes with methods longer than 400 lines. And then one tries to remember what that abbreviation was and looses it X|
regards Torsten When I'm not working
-
...that comes with methods longer than 400 lines. And then one tries to remember what that abbreviation was and looses it X|
regards Torsten When I'm not working
it normally takes me a day and a notepad to work it out oh and a large supply of :java:
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
-
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
My favorite variable names are:
$_
$#
$^W
@ARGVThe full list can be found here: http://affy.blogspot.com/p5be/ch12.htm[^]
-
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
public class MehGerbilToldMeToEvenThoughItFeelsWrong_Record
{
public string MehGerbilWouldBeProudOtherwiseIWouldntDoThis_RecordID { get; set; }
public void ImStartingToThinkIMightHaveAProblem();
} -
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
I agree 100% But I also try to find names that are as short as possible, but accurate and descriptive. I also hate underscores, I much prefer camelCasing and PascalCasing. I use camelCasing for private names & local variables, and PascalCasing for public and class names.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
My favorite variable names are:
$_
$#
$^W
@ARGVThe full list can be found here: http://affy.blogspot.com/p5be/ch12.htm[^]
ah, perl, a synonym for "line noise".
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
I usually use GUIDs for a variable names – secure and consistent.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
I usually use GUIDs for a variable names – secure and consistent.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
And easy to remember for any real geek :)
-
After 10 years of experience I've a tendency to fully spell out variable names in my code and in field names in my databases. I used to shorten things but I found over time that abbreviated names have a tendency to be very inconsistent from class to class or database to database. I'm getting too old to remember clever naming conventions. For example, in a production database that I'm currently slogging through (designed by someone else) the word OBJECT in some field names is OBJECT, while in others it's OBJ much like this: FIN_OBJ_CODE, OBJECT_CD_NM. As you can see, CODE also changes from CODE to CD depending upon the field. For a field that holds 'object code name' you could have: OBJ_CD_NM OBJECT_CD_NM OBJECT_CODE_NM OBJECT_CODE_NAME OBJ_CODE_NM OBJ_CODE_NAME OBJ_CD_NAME WTF_I_FORGOT_TEH_NAME By the time you spread that nonsense through parameters, objects, object properties, fields and so forth one might end up with a dozen or more names for the exact same field. objCodeName _OBJECT_CODE_NAME ObjectCodeName _strObjectCodeName @INeedANewJob NameObjectCode It may get a wee bit tedious that times but now I just spell out the entire name of the field whether I'm naming a table, field, property, parameter or whatever. In the long run I find it less confusing. In the example above, everything is ObjectCodeName. Does anyone else do this or is it just us early onset Alzhemier's victims?
I do that as well. I tend to use complete words in most of my names. The only ones that get abbreviated tend to be
forloop index variables:PHiinstead of 'printhead index', for example.Software Zen:
delete this; -
for ( int i=0; i<10; i++)
{
for ( int eye=0; eye<10; eye++)
{
for (int aye=0; aye<10; aye++ )
{
}
}
}for ( int i=0; i<10; i++)
{
for ( int eye=0; eye<10; eye++)
{
for (int aye=0; aye<10; aye++ )
{
for (int aargh=0; aargh<10; aargh++ )
{
}
}
}
}Sorry, couldn't resist
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
