Programming style question



  • I would encourage descriptive names used for every variable. If you meant using i as an increment counter for a for loop, which you seem to, than that is fine. It's common to see it:

    for(int i=0; i<x; i++)

    Really? I thought it was my own invention http://www.google.com/codesearch?q=%22int+i%22&hl=en&btnG=Search+Code . Forgive a bit of sarcasm but you not only state the obvious but also go off topic. I asked for pointers to reference not for style guidance.
     

    I think of i as an increment or index. In the programming community the majority of developers should recognize this. However, when it comes to VB .NET I generally say intIndex instead, simply because VB .NET's syntax is more word like and having a single character variable name in the middle doesn't flow well. Usually the for loops iteration variable is used to index something; hense, intIndex.

    See above. 

     

    I can't remember ever seeing c used for an input character so I would shy away from that. I would recommend you use a more descriptive name. And although I've seen pos used on occassion, a more descriptive name would still be a benefit here. This one is more personal preference since it's still pretty easy to guess what it represents.

    You've never seen while ((c = getchar()) != EOF) ? Whoa. You might want to have a glimpse at ANSI C by K&R. Also, http://www.google.com/codesearch?hl=en&lr=&q=%22char+c%22&btnG=Search

    The length of variable names shouldn't affect the actual program execution: I assume variable names are all replaced with an index or address in the binary executable. Make your variable names as descriptive as necessary to see it and immediately have a good guess as to what it represents. That said, don't make variable names longer than they need to be. That's just more work for yourself and other programmers that maintain the code.

     Overly long names make even simple expressions exceed standard line length. Same for function calls.

    Btw, it occured to me that PositionInLineFromLeftSide is not only redundant but also plain wrong. When we get characters from standard input there's in fact no left side. I imagine that if I used an Arabic terminal (if such a thing exists) than beginning of the line would be on the right. Thus, beginning, not left side. And the default for the beginning is the beginning.



  • please don't come asking for opinions if you are just going to be a dick when you don't agree with the opinions given.



  • I asked for pointers to reference not for style guidance.

    Besides, at least I'm not calling people names.
     



  • Tstr, Jergosh is reacting to that the responses given are tangential to the question he asked. Understandable, but (1) the OP was somewhat open and inviting of discussion, and (2) the thread has long since veered away from the OP's question, which is very common and just to accept. No-one "owns" threads in public forums, and no thread, unless actively policed by moderators, will stay on a single course for very long, which also happens to be the generally desirable development since it allows for the possibility of stimulation and creativity beyond the original question and the OP's scope.

    In short, and in clearer language, Jergosh, get over your notions of owning the thread or having rights to dictate its contents.



  • I'm not aspiring to control the discussion, I hoped to get answers to my question  and so far I got 4 of them (out of 54 posts).

     

    For the record, in the meantime I found an excellent quote from The Practice of Programming by Brian Kernigham and Rob Pike:

    "Programmers are often encouraged  to use long variable names regardless of context. That is a mistake: clarity is often achieved through brevity."



  • @jergosh said:

    btw, it occured to me that PositionInLineFromLeftSide is not only redundant but also plain wrong. When we get characters from standard input there's in fact no left side. I imagine that if I used an Arabic terminal (if such a thing exists) than beginning of the line would be on the right. Thus, beginning, not left side. And the default for the beginning is the beginning.

    Excellent point.

    @jergosh said:

    I'm not aspiring to control the discussion, I hoped to get answers to my question  and so far I got 4 of them (out of 54 posts).

    Now, that's only half our fault -- talking about variable naming will invariably turn into a flame war.

    @jergosh said:

    For the record, in the meantime I found an excellent quote from The Practice of Programming by Brian Kernigham and Rob Pike:

    "Programmers are often encouraged  to use long variable names regardless of context. That is a mistake: clarity is often achieved through brevity."

    Note that they don't suggest that it's better to always use a short variable name, only that *context* and *clarity* are the key. If you have a short function, and it's clear from context what i and c stand for within that function, then i and c are perfectly valid. If you've got a longish function with a dozen local variables, i and c could get lost in the shuffle. Use your common sense. Also, go upside the head of whatever TA suggested PositionInLineFromLeftSide and tell him it's from me.



  • Note that they don't suggest that it's better to always use a short variable name, only that *context* and *clarity* are the key. If you have a short function, and it's clear from context what i and c stand for within that function, then i and c are perfectly valid. If you've got a longish function with a dozen local variables, i and c could get lost in the shuffle. Use your common sense. Also, go upside the head of whatever TA suggested PositionInLineFromLeftSide and tell him it's from me.

    I'm aware of that, I find this fragment useful because I'm taught to use long variable names regardless of context ;) 



  • You only got 4 answers I would think because the correct answer had already been given 3 or 4 times.  I didn't give an answer because I didn't feel like writing the exact same thing down as someone else.

     

    PS.  sorry if I thought you were responding to the wrong thing :) 



  • @jergosh said:

    I can't remember ever seeing c used for an input character so I would shy away from that. I would recommend you use a more descriptive name. And although I've seen pos used on occassion, a more descriptive name would still be a benefit here. This one is more personal preference since it's still pretty easy to guess what it represents.

    You've never seen while ((c = getchar()) != EOF) ? Whoa. You might want to have a glimpse at ANSI C by K&R. Also, http://www.google.com/codesearch?hl=en&lr=&q=%22char+c%22&btnG=Search

    Just because a lot of people have done it doesn't mean its standard practice.  Two of the worst possible variable names, "data2" and "stuff", also have many hits on google code search.

    As for this thread being off topic, I would guess it's because most people here can't think of a programming reference that specifically warns against long variable names.  Also, when you post something that people might not agree with (like your assertion that "pos" is a standard naming convention), you should expect people to post arguing that you are wrong.



  • I notice a lot of people here have been talking Hungarian notation. I was just stumbling across this article from IBM (on data types in C) which took a moment to say...

    Someone once proposed an elegant and effective way to improve the quality of code: prefix variables with something indicating their function. For instance, the prefix ct might indicate a counter. The proponent, Charles Simonyi of Microsoft, was originally from Hungary, and the pattern became known as Hungarian Notation (for more information about Hungarian Notation, see Resources).

    Then tragedy struck. Someone who had entirely and catastrophically missed the point of Hungarian Notation started using it to denote, not the usage or function of variables -- their "type" in an abstract sense -- but the specific language type chosen to implement them. For instance, instead of using prefixes to distinguish between counters and array indexes, you would use prefixes to distinguish between int and long.

    There is no better word for it: This is stupid.

     

    As for the professor in question, well, aside from any stupidity on his part, I think he is trying to at least drill it into the (oft thick) skulls of students to "Use Meaningful Variable Names!!!" and other best practices like that - and if he carries it to an extreme, after they have left his tutelage and are working in the real world at least they might sort of do it sometimes as a result. :P 

     



  • @fennec said:

    Someone once proposed an elegant and effective way to improve the quality of code: prefix variables with something indicating their function. For instance, the prefix ct might indicate a counter. The proponent, Charles Simonyi of Microsoft, was originally from Hungary, and the pattern became known as Hungarian Notation (for more information about Hungarian Notation, see Resources).

    This is less pointless than prefixing by type, but I would hardly call it elegant or effective.  How is ctMatch in any way better than matchCounter?  Sure, using "ct" shaves off 5 characters, but now you have all of the usual Hungarian headaches.  It's harder to read, you have to know what all of the prefixes mean, you can't have use the same prefix for similarly spelled words, etc.



  • @burnmp3s said:

    This is less pointless than prefixing by type, but I would hardly call it elegant or effective.  How is ctMatch in any way better than matchCounter?  Sure, using "ct" shaves off 5 characters, but now you have all of the usual Hungarian headaches.  It's harder to read, you have to know what all of the prefixes mean, you can't have use the same prefix for similarly spelled words, etc.

    I believe it was introduced at a time when varable names were still restricted by compiler and the concepts of RAD and intellisense didn't exist.

    I agree -- matchCounter *is* better, although in this case I'd suggest that matches or numMatches would be even better.



  • I have found it useful in reading code to know what type I'm dealing with, and it also makes it easier to name variables when there are different data type variables for the same value. For example, and I don't have a good one off the top of my head,:

    [color=blue]Dim[/color] intNumberOfMatches As Integer = 5
    [color=blue]Dim[/color] strNumberOfMatches As String = Convert.ToString(intNumberOfMatches)

    If you simply called your initial integer counter NumberOfMatches, but also needed a string version for whatever reason, you would end up with a different name for the same variable... Which could be confusing to other programmers maintaining your code. With the above example, it should be pretty obvious to anybody that has seen Hungarian notation that the variables should represent the same value in their respective data types.

    I know it's a poor example, but I don't have a good one right now.



  • @xtremezone said:

    I have found it useful in reading code to know what type I'm dealing with, and it also makes it easier to name variables when there are different data type variables for the same value. For example, and I don't have a good one off the top of my head,:

    [color=blue]Dim[/color] intNumberOfMatches As Integer = 5
    [color=blue]Dim[/color] strNumberOfMatches As String = Convert.ToString(intNumberOfMatches)

    If you simply called your initial integer counter NumberOfMatches, but also needed a string version for whatever reason, you would end up with a different name for the same variable... Which could be confusing to other programmers maintaining your code. With the above example, it should be pretty obvious to anybody that has seen Hungarian notation that the variables should represent the same value in their respective data types.

    I know it's a poor example, but I don't have a good one right now.

    It sort of hinges on examples, really. One can argue a lot using academic and thought-up situations, but if the amount of proper examples is 0, then one has no case.

    Maybe this is a better example:

    strMonthNames = "Janurary,Februari,March,April";
    arrMonthNames = strMonthNames.split(",")


  • @VGR said:

    @rmr said:
    @Whiskey Tango Foxtrot? Over. said:

    IGNORE THIS PERSON!!!!!!!!!!

    Hungarian notation is a plague that must be stamped out wherever it arises! SHAME ON YOU, mruhlin FOR PROMOTING IT!!!

    Chill out.

    Actually, I was thinking he should have used a little more emphasis than that.

    Hungarian is an abomination. It represents sheer contempt for one's co-workers, drags productivity into the gutter, and shows a staunch resistance to OO.

    int main(int iArgc, char** papacArgv) {}

    (pointer to an array of pointers to an array of chars, Hungarian notation gone bad :D. If you want to be pretty I guess you could include the fact that they are null terminated somewhere. Yes, the default arguement array is also null terminated.)



  • @Daid said:

    int main(int iArgc, char** papacArgv) {}

    (pointer to an array of pointers to an array of chars, Hungarian notation gone bad :D. If you want to be pretty I guess you could include the fact that they are null terminated somewhere. Yes, the default arguement array is also null terminated.)

    Lol, also good of you to insert a bonus idiom failure into the snippet to really drive home and compound the wtf: "[b]char**[/b] papacArgv", where you create additional confusion by visually connecting the type specifier to the data type declaration when all proficient C/C++ coders would write (still using hungarian, of course) "char ppcArgv" or "char ppcArgv".



  • @jergosh said:

    I was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide 

     

    ForLoopCounter, InputCharacter and PositionInLineFromLeftSide are EVIL. variable names.

     

    In the same vein, why not

    FunctionArgument, FunctionReturnValue, WhileLoopCondition, TrueOrFalseBoolean, VeryImportantVariable, DisplayUserDialogueAndGetReplyFromUserOKorCancel

    and of course the name of program

    ThirtyLineTextProcessingProgramWithAVeryLongNameBecauseMyLecturerIsAnIdiot 

    I dare you to shorten pos to p, just to see the reaction :-)



  • @Daid said:

    @VGR said:
    @rmr said:
    @Whiskey Tango Foxtrot? Over. said:

    IGNORE THIS PERSON!!!!!!!!!!

    Hungarian notation is a plague that must be stamped out wherever it arises! SHAME ON YOU, mruhlin FOR PROMOTING IT!!!

    Chill out.

    Actually, I was thinking he should have used a little more emphasis than that.

    Hungarian is an abomination. It represents sheer contempt for one's co-workers, drags productivity into the gutter, and shows a staunch resistance to OO.

    int main(int iArgc, char** papacArgv) {}

    (pointer to an array of pointers to an array of chars, Hungarian notation gone bad :D. If you want to be pretty I guess you could include the fact that they are null terminated somewhere. Yes, the default arguement array is also null terminated.)

     

    you just described a (char ****)


  • Hungarian notation saves the day!

    We're porting code from a newer version of our product to an older one (yeah, that's a big WTF right there).  Anyhow, we're testing it, it breaks, and I get the following IMs:

    [10:38] JW:  this is why I frekkin' hate going BACKWARDS
    [10:39] JW:  9.3+: oNotifyEvent[EK_TRANSACTION_ID] = nTransactionId;
    [10:39] JW:  9.1: oNotifyEvent[EK_TRANSACTION_ID] = szTransactionId;
     

    Debugging made easy.

    /Just to clarify, it had actually been changed from a string to an int, not just renamed by some jackass. 



  • Seriously, what the hell does "oSomeThing" get you? It's embedded in the name....

    0

    Nothing

    Zip

    Nada

     



  • Seriously, what the hell does "oSomeThing" get you? It's embedded in the name....

    0

    Nothing

    Zip

    Nada

     

    Yup yup yup.


    Exclusive datatype Hungarian is useless.

    Business or Apps Hungarian is useful.

    When an App/program rule coincides with the datatype, then a datatype indicator might be useful -- but that depends on the typing model and syntax of a language.

    I think that sums it up, sorta.
     


Log in to reply