Variable Names
-
"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 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 seem to remember using a version of Basic (TRS-80?) where i and j were predeclared integers and x, y floats?? Or maybe I was dreaming...
-
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
MehGerbil wrote:
earning twice what I make.
Because the code fairies saw no reason to punish him because he did not use hungarian notation. It's like an OSS project I worked on - the hungarian notation for a class was 'x' followed by a capital letter (which is two extra keystrokes). Pretty-much everything was a class and therefore 'x' was used for pretty-much any variable. It added absolutely no value to the quality of the code because everything was just 'x'. New developers would think that we just added them in front of everything so they didn't ever use the usual 'i', 'd', 'f', 'h' etc. It was completely wrong in the first place because a 'reference type' (class) should be an 'h' because it's a pointer. I only have a limited amount of keystrokes available in my life and I quickly decided to expend them on other things. Some nights I dream about each dying kitten as a developer uses hungarian notation. I don't think the code fairies will ever forgive me: the dreams won't stop.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Not at all. Fortran had pre-declared integer and float variables.
Wagham I'm just too old to really give a damn!!
-
"x" and "y" are perfectly valid variables: particularly when you are talking about co-ordinates:
foreach (Control c in Controls)
{
c.Location = new Point(x, y);
x += horizontalSpacing;
y += verticalSpacing;
}Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
*ONLY when you are talking about co-ordinates. Fixed that for you.
-
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 use VisualAssist for VS which lets me type acronyms (such as
ocn) and immediately offers a selection of valid symbol names in a pop down list, including pretty much all of your above suggestions. Therefore I always use full names, even if that results inveryLongVariableNames. I still wonder whether to use camel case or separate words by '_' instead. I feel I should be doing the latter, but am loathe to change style while working on the same project. ;) -
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?
-
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've had to work with some real turkeys in my time. At one place there was a developer that named all his routines after Disney characters.
BALR 8, GOOFY
At another place consultants had created alphabet soup.
int Routine(a, b, c, d, e, f, g, h, i)
One person I worked with believed all variables and routine names should be 8 characters long (if possible). You take 8 divided by the number of words in the full description to get the number of letters to use from each word. So the print spooler was called
PRINSPOO
Not so bad, but Shipping Station Control Loop became...
SHSTCOLO
Another believed in using the maximum number of letters allowed by the compiler. So he'd come up with goofy stuff like
FireHunterSeekerBlowBackTo
Which didn't even work as a comment. The worst part was that he couldn't speel :) so these long ass variable named routines and variables would have to misspelled everywhere they were used. So you had to remember the long names and how to misspell them. Myself, I like to go with what works. Sometimes I use Hungarian, mostly for controls, but sometimes for variables if I think it will help me remember the limitations of the type. I don't believe in enforced standards. I believe in consensual styles. Development environments change too much over the years and straitjackets are only for the insane.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
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?
Were you a Cobol progammer earlier?
-
"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".
-
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 rule of thumb is: Use whatever meaningful: Camel, Hungarian, Abreviate ... However, 1. If variable length is greather than 10 characters, I usually find a way to abbreviate, whenever possible. I realized that code turns into addresses and variable length has no meaning, but I don't what to write a 100+ worth of characters just to add couple of values. 2. If variable is an object and it is not quite obvious of its type (usual GUI compoents), I add hungarian notation. 3. Personally I don't like underscore, especially prefix like _myVar. However, I still use it wherever make sense.
-
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 also do, and I do feel the onset of Alzhemier. At my last job, my co-worker shortened var names to the point where LN could be "Loan Number" at times, and at other times it ment "Last Name". It drove me nuts :( He would say, "I guess you just like to type."
-
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?
Over the years, I have gotten much more verbose with variable and database column names. I've actually gotten quite lazy and begun using the field names for the variable names in certain situations...automatic mapping...makes it really easy to create update and insert statements. camelCase is what I have always used, but starting to use more under_scores...seems to read better for me, or my eyes are getting worse! For UI controls, it's always hungarian. Using longer, more descriptive names makes the code self-documenting and easier to follow. I do have a standard set of 2 and 3 letter variables that I use for common operations such as db, rs, bs, lc (loop counter), and sql.
"Go forth into the source" - Neal Morse
-
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 BraunI've never really understood the indiscriminate use of the "camelCasing" form. Sure, there's a role in JAVA for the use case of verbNoun but I see others using this form for no obvious reason. I just don't really like it. Two things: 1) Consistency whatever standard is imposed should be used everywhere. 2) No single letter variables. If it is worth storing something, it is worth giving it a name. Unless you have a fancy editor (like in Eclipse) where the IDE can show you where the variable is used in a function, it can be damn difficult tracking them down using search tools.... My 2p
-
Well shouldn't you call them d19dad80-fbb5-4350-b62b-8326e02ae2ecs? :)
-
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 the same. Being fairly new to database development, I have also had a hard time dealing with other people's abbreviations. I will always be happy when people spell out explicitly what they mean. I will NEVER thank someone for using abbreviations, even if they are consistent, even if they make sense after a single explanation. My opinion is that there should be no explanation required (if it needs explanation it probably really just needs a better name). Another thing that DBs are constantly short on is comments, it seems like there are tons of database's out there in production and I have yet to see one where each table has comments, even if the code is well documented for the solution (MySql specifically, I don't know if other RDBMS have the ability for comments as well but I hope they do). Anyway, thanks for the opportunity to rant a bit.
-
I once employed a chap who wrote a very complex bit of graphics manipulation software for me - he was off to Norway with it the next day and worked through the night to get it running, which he did - much to my amazement. When I later looked at his code, each function was full of meaningfully named variables: x, xx, xxx, xxxx and - of course - y, yy, yyy, yyyy. No-one, including him, could ever understand how that code worked, or dared to amend it...
-
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'.
I never abbreviate anything that's in any way externally accessible - private members of classes fall into this category, they're external to the methods using them. Rarely, if the scope they're used in is very small (like a block of five lines between braces), I use abbreviations - and I consider this to be a bad habit. Reason: the block might grow without somebody thinking to rename the variable, and even if the block stays short, abbreviations decrease readability for someone not familiar with the code. Cf. Martin Fowler, speaking names are the cheapest way to properly document your code - they don't need extra maintenance, like comments do, and they're checked by the compiler/interpreter. Why give up these advantages by using abbreviations?
