Programming style question



  • I recently had a bit of, erm, heated discussion over variable naming in my programming assignment. I followed the standard naming convention of calling an int 'i',  a char 'c', position in line 'pos' etc. but was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide respectively (on may say wtf?!). Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?

     

    TIA,

    J. 



  • The best use for large tomes in such a discussion is to beat the other people about the head until they shut up.

    Otherwise you'll just get into a lengthy argument about who constitutes an authority. That's always a waste of energy that could be far more productively employed (in violence).



  • I don't know of any authority that forbids using standard naming conventions.



  • From Code Complete by Steve McConnell p 262:

    "Gorla, Benander and Benander found that the effort to debug a program was minimized when variables had names that averaged 10 to 16 characters (1990).  Programs with names averaging 8 to 20 characters were almost as easy to debug." 

    That said, naming conventions are a religious issue among programmers.  I think the most enlightened thing you can do is not waste your time arguing about it, since it is completely unlikely that you will change any minds.

    Btw, "programming assignment"?  So can I assume that you are a student and the debate was with your teacher?  In that case, definitely do what your teacher tells you to.  When you have to maintain someone else's code you'll be thankful if they followed your teachers convention and not yours.



  • @jergosh said:

    I recently had a bit of, erm, heated discussion over variable naming in my programming assignment. I followed the standard naming convention of calling an int 'i',  a char 'c', position in line 'pos' etc. but was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide respectively (on may say wtf?!). Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?

     

    TIA,

    J. 

     I would disagree on the ForLoopCounter, as this would get you into the same trouble again when you do for-loops in the for-loop. InputCharacter sounds ok to me, but PositionInLineFromLeftSide could be renamed PositionInLine, unless you frequently count from the right side as well (counting from left to right is kind of default, at least where i'm from). The amount of typing needed is not that much more with modern code-completion, and the amount of extra reading is negligable as well.

     http://www.joelonsoftware.com/articles/Wrong.html might be worthwhile reading if you're interested in these type of things. At the start it seems to be about a bakery, but trust me, it isn't.
     



  • @rmr said:

    From Code Complete by Steve McConnell p 262:

    "Gorla, Benander and Benander found that the effort to debug a program was minimized when variables had names that averaged 10 to 16 characters (1990).  Programs with names averaging 8 to 20 characters were almost as easy to debug."

    Why do I get the feeling that there are people out there who will have read the above and switched to:

     string aaaaaaaaaa;
     int bbbbbbbbbb;
     

    Anyway, single letter vars suck (unless it makes sense, eg x and y in a coordinate system), and following the "c for char" rule, what do you do when you're juggling 50 chars? c1, c2 ... c50? Just call it what it is (verticalOffset, age) etc. ForLoopCounter is just as evil. It tells you nothing. for-looping through pages in a book? Call it pageIndex or something like that.



  • That Joel article is great!  Everyone should read it.

    And yeah, ForLoopCounter is pretty terrible.  It gives no more information than the standard variable name i, which can pretty much be assumed to be a for loop counter.  Personally, I like to use something like rowIndex or colIndex.

    Look at me getting all caught up in the naming conventions religion debate. . .



  • @jergosh said:

    I recently had a bit of, erm, heated discussion over variable naming in my programming assignment. I followed the standard naming convention of calling an int 'i',  a char 'c', position in line 'pos' etc. but was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide respectively (on may say wtf?!). Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?

    <FONT size=2>

    ForLoopCounter is useless, it doesn't tell you anything more that "i" does. Personally I only use "i" if all I'm using it for is as an array index. Otherwise if I'm counting retries for example I'll call it retryCount. I tend to use foreach loops and collections over arrays so I don't have very many normal for loops anyway.

    The other two are okay. I would probably go with inputChar because char is one of the only abbreviations I use. I would also probably use linePosition or leftPosition for the other one.

    There aren't many programming books that would suggest using "pos" or "c". Most of them even suggest using big pretty comment boxes above functions though, so they don't all represent what actually works in the real work. I personally like the practices in Code Complete</FONT><FONT size=2>.</FONT>

    <FONT size=2>It's hard to understand why you need to use good variable names until you try to maintain code from someone else who uses bad variable names.

    </FONT>


  • Their suggested names are a bit stupid.  I've lately become a fan of hungarian notation:

    http://en.wikipedia.org/wiki/Hungarian_notation

    ForLoopCounter is just asinine when everybody knows what i means.

    Your use of 'c' for the char seems a bit too abbreviated though, depending on how arbitrary the character is.  Calling it "InputChar" makes me think it's being used as the input to a function.  Should generally have a name that's relevant to the function.  cTarget if you're searching.

    PositionInLineFromLeftSide?  Go ahead and call it nPos or nLocation.  Actually, make it unsigned too uLocation.



  • @vt_mruhlin said:

    Their suggested names are a bit stupid.  I've lately become a fan of hungarian notation:

    http://en.wikipedia.org/wiki/Hungarian_notation

    ForLoopCounter is just asinine when everybody knows what i means.

    Your use of 'c' for the char seems a bit too abbreviated though, depending on how arbitrary the character is.  Calling it "InputChar" makes me think it's being used as the input to a function.  Should generally have a name that's relevant to the function.  cTarget if you're searching.

    PositionInLineFromLeftSide?  Go ahead and call it nPos or nLocation.  Actually, make it unsigned too uLocation.

    Coming from a VB background, my advice is to stay very far away from hungarian.  It sounds like a good idea at first, but it only works well for primitive types (hopefully you are using OO or at least your own structures) and it can cause problems if you change the types of your variables often (through refactoring or other methods).

    If you're using a statically typed language just get a decent IDE so you can just mouse over a variable to find its type.

    Also, to the OP, here is a link to an instructor who explicitly warns against using long variable names (http://www.eng.fsu.edu/~dommelen/courses/cpm/notes/progreq/node5.html#SECTION00050000000000000000).



  • The programming style depends on the programming language. For example, in PL/SQL, it makes some sense to prefix all variables with v_, since you have a lot of statements like

    select name into v_name from person where id = v_id;

    (Unlike T-SQL, there is no syntactical difference between a database field and a PL/SQL variable... but many PL/SQL variables refer to database fields or tables...) 

    Using the same naming convention in Java would be plain stupid.



  • @burnmp3s said:

    Coming from a VB background, my advice is to stay very far away from hungarian.  It sounds like a good idea at first, but it only works well for primitive types (hopefully you are using OO or at least your own structures) and it can cause problems if you change the types of your variables often (through refactoring or other methods).

    If you're using a statically typed language just get a decent IDE so you can just mouse over a variable to find its type.

    Read the article mentioned above what hungarian was meant to be like. The type-based hungarian is senseless, especially in OO languages. 



  • All depends on variable scope. The more your identifier has to be used externally, the more you need explicit names ; on the other hand don't bother with explicit loop variable. LoopVariable is ridiculous as it does not bring any more information than the conventional i in indexes. Evolving languages even tend to avoid that kind of variable when it can be replaced by a more obvious language construct : who needs an array index when you have iterators or even ruby blocks ?

     As I'm a big fan of joel I'm going to re-read the article linked above, but there's one great lecture that I consider crucial : Refactoring by Martin Fawler. Don't focus on the fact that refactoring is about rewriting existing code ; any living code needs incremental changes, and having this knowledge is a good remedy against over-designing applications. A good design is crucial indeed, but the fact is there is always a moment when you have to admit some decisions are unpractical, some naming convention is boring, some processing is not at its place and needs to be isolated in its own class. Never try to be perfect from the very start ; pick up a decision, you'll have to reorganise your code sooner or later anyway. Then your codebase will adapt to adapt.



  • @jergosh said:

    I recently had a bit of, erm, heated discussion over variable naming in my programming assignment. I followed the standard naming convention of calling an int 'i',  a char 'c', position in line 'pos' etc. but was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide respectively (on may say wtf?!). Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?

    Variable names should be SEMANTICALLY descriptive as opposed to syntactically descriptive. "ForCounter" says nothing about the intention of the variable, only about its syntactical functionality. The ideal is that the source code should be self-documentary, and to that end proper naming of variables is essential. Therefore, length of variable names is a moot question, while the power of description of the names becomes the real question.

    This gains in importance the longer the block of code the variables will appear in. If the function is very short and not riddled with legions of variables and thus easy to overview, then you can afford to be more lax, in fact, in short snippets overly long variable names are tedious and rather mess and clutters up the code than facilitates transparency. In short loops and similar constructs short, even one-letter, variable names may be perfectly valid. A canonical example is a "for (int y; y < height;++y) for (int x; x < width;++x) do_magic(x, y);" loop.

    However, if your code is well-designed, that is, your code is already divided into well-defined functions/methods, there are principally no global variables, etc., then your code will be transparent and variable names should be less of an issue. If your code is not well designed then your variable naming scheme is just one thing among many you'll have to work on.



  • @vt_mruhlin said:

    Their suggested names are a bit stupid.  I've lately become a fan of hungarian notation:

    http://en.wikipedia.org/wiki/Hungarian_notation

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

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

    That said, I agree with him (or her) and the consensus here that ForLoopCounter is asinine. It's an example of taking a Good Idea (tm) Too Far (c).

    When it comes to naming variables, descriptive *is* better -- as long as it makes sense. 'i' is universally accepted as an index into an array -- when it's the only index in question. What happens when you're indexing two or even three arrays? Then you need more descriptive names, like 'row' and 'column' or even 'rowIndex' and 'columnIndex' (if your arrays happen to be named 'row' and 'column'). I would argue that 'pos' is probably too short -- 'position' would be better. PositionInLineFromLeftSide...? Too much. Unless you happen to have more than one position that you're using inside your method/function. PositionInLineFromLeftSide might make sense if there were also PositionInLineFromRightSide, PositionInLineFromMiddle, PositionFromTop, PositionFromBottom, etc. Although those could probably be shortened to 'top', 'bottom', 'left', 'right', 'middle', etc.

    Also, I don't think it's been mentioned, but you should probably consider adopting some form of scoping guidelines for names. I prefer most of the "C#" style guide -- classes, parameters, attributes, and methods should be named using PascalCase, while in-method variables (like every one of the examples listed in the original post) should be named using camelCase.



  • @Mikademus said:

    Variable names should be SEMANTICALLY descriptive as opposed to syntactically descriptive. "ForCounter" says nothing about the intention of the variable, only about its syntactical functionality. The ideal is that the source code should be self-documentary, and to that end proper naming of variables is essential. Therefore, length of variable names is a moot question, while the power of description of the names becomes the real question.

    Quoted for truth.



  • @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.



  • All this regards, as I probably should have said in the first place, a twenty line text processing program where there's only one char var and two ints. Curiously enough, those single letter naming conventions are used in K&Rs ANSI C which happens to be our textbook. Personally, I'm all for descriptive names and would settle for, say, 'positionInLine' but my lecturer claimed that 'only I know that c is a char' and 'only I know that the position is from the left' which led to me to asking here for pointers to literature (which btw != 'What naming conventions are best?'). That said, many thanks for all the replies.

     

    [quote=RayS]what do you do when you're juggling 50 chars? c1, c2 ... c50?[/quote]

    You've never heard of strings, arrays or data structures in general, have you?



  • K&R is great, but a style guide it is not.

    And, uh, I think RayS has heard of arrays. 

    Here's some reading you might benefit from: http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
     



  • @jergosh said:

    ...which led to me to asking here for pointers to literature (which btw != 'What naming conventions are best?')...

    Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?

    Sorry for the misunderstanding. To better answer your question: I've read quite a few books on software development, and I've *never* read a book that suggested, hinted, implied, or otherwise stated that short variable names were better than long ones. Invariably, the more descriptive a variable is named, the better. Now, there are some older texts that will lament that variable names can only be so long -- due to compiler or language design constraints -- but in this day and age, that's not an issue. Good luck searching, but you're not gonna find many.

    That said, if your professor is claiming that PositionInLineFromLeftSide is the only valid name for a variable, he either a) doesn't get the intentions of descriptive variable names and thus blindly follows the "letter of the law", or b) is one of those guys who (stupidly) thinks that you should never, ever, write a comment in or about your code, since if it's "done right" your code will speak for itself. Given what you've said (a text processing program with three variables), your variable is better named as "position", with an accompanying comment that it represents the position of the character in the line, from the left side.



  • The use of single letters and other short names depends on the context. More than anything else, you want to choose whatever results in the most readable code.

    "i" is a good name for a loop variable because it's a common convention in mathematical summation expressions. "ForLoopCounter" is obnoxious and will make for code that's dreadfully hard to read. If I were asked to maintain it, the first thing I'd do is replace "ForLoopCounter" with something short so I can make sense of the code.

    Whether you want to use "c" or "pos" depends on what you're doing. For instance:

    int countUppercaseLetters(String s) // generic string

    void setName(String newName)

    The first method's String parameter really can be any String, so giving it a verbose name won't help anyone who's reading the code.

    Similarly, you might use "char c" if you're reading characters from a stream and don't care what they are, but in other cases you would want to give it a meaningful name:

    char response = inputLine.charAt(0).toLowerCase();



  • @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.



  • My rule here is: if I can think of a short, unambiguous name for a variable, such that the name clearly describes the purpose of the variable with no plausible confusion, then use that name. If I can't - if every name I can think of is ambiguous because there's just too many things going on here and it could be referencing several of them - then the variable name should be meaningless. I typically use single characters for convenience. The trick here is that even a meaningless name conveys a little information: it says "you are going to have to look at this carefully in order to understand what this variable does".

    You always add a comment explaining what it does, of course. The essential point is that a meaningless variable name is better than a confusing one, because at least when the name is meaningless then the maintainer has no choice but to think through what the code is doing.

    (It also serves as a way to highlight code that is too complicated and in need of rethinking when you've come up with a better idea for how to approach the problem) 



  • Personally, I like the idea of naming variables according to their lifespan and importance.

    In this for loop, for example, "i" is perfectly acceptable because you can see at a glance what it does:

    for (int i = 0; i < array.length; i++) {
      System.out(array[i];
    }

    If the body would be 20+ lines long, I'd call it "index" or something. For member variables or even global ones, the more descriptive you can be, the better.

    As far as Hungarian notation is concerned: Please read Joel's blog entry linked above. The original idea of "apps hungarian" seems to be very sensible in that context. I can imagine using this in a physics engine or something like that, where you have a lot of variables of the same type with different semantics (speed, position, force etc), and the notation helps you to not mix them.



  • "ForLoopCounter" is too long.
    "PositionInLineFromLeftSide" is WAY too long. Reading is hard, and more chars = more clutter. The atom of information for a human brain is the Word. Sentences have to be dissected for meaning; single characters have to be mentally expanded. That takes precious time. Your brain has to do it every time it sees a char or a sentence. Although some learning can occur ("caching" if you will), that learnt information becomes obsolete when the next program is viewed.

    "c" is too short. single-char variable names make them vanish against the background of operators, tokens and keywords. Remember that when you obfuscate code, one technique is to replace as many vars as possible with single-char names.

    "i" is juuust right because it's part of programming idiom. It's an exception. Exception.

    There is a balance, a sweet spot, between long and short names. Personally, I tend to allow longer function names, and try to keep varnames a little shorter. Datatype Hungarian is utterly pointless. strThis and intThat has no informational value. It's noise. Apps hungarian has its place. I try to stay below 5 words. An issue is that if your function/proc needs a very long name, it's possibly overloaded and could benefit from being split into two+ functions.



  • i dissagree, i often name my function names like small sentances

     get_blogpost_by_name($blogpost_name)

     get_blogpost($blogpost_id)

    get_blogposts_by_tag($tag_id); 



  • @stratos said:

    i dissagree, i often name my function names like small sentances

     get_blogpost_by_name($blogpost_name)

     get_blogpost($blogpost_id)

    get_blogposts_by_tag($tag_id); 

     Yup, it should come as a consensus that naming conventions heavily depends on programming style and syntax.

    If it's pure procedural - or if procedural style is preferred because OO syntax looks horrible in your language ( sorry to say I just hate OO syntax in php and perl, all those '$' and '->' clobber the screen for no reason ) - code is more readable if function names sound like phrases.

    When it comes to objects, one verb is enough since you know what it applies to : in RoR , we have BlogPost.find_by_name(name), BlogPost[id] or BlogPost.find(id) , and finally BlogPost.find_by_tag_id(tag_id) or better, Tag[tag_id].blog_posts which makes more sense.



  • @aikii said:

    [..snip...] 

     and finally BlogPost.find_by_tag_id(tag_id) or better, Tag[tag_id].blog_posts which makes more sense.

     

    firstly i (almost) totally agree with your post, and guilty as sin i need to write in a language with dollar signs all day. Well what kan i say it's a commercial company and my boss likes money.
     

    but secondly the later will make your Tag code know about blogs.
    but the first one will offcourse let the blog know about tags.

    mmm.

    how about this

    BlogPost.find_by_ids(Tag[tag_id].get_items());

     

    ermmm but pretty offtopic this :P 

     

     



  • @stratos said:

    firstly i (almost) totally agree with your post, and guilty as sin i need to write in a language with dollar signs all day. Well what kan i say it's a commercial company and my boss likes money.


    I guess you should be given more credit for keeping things clear when a language doesn't help :) 

    @stratos said:

    but secondly the later will make your Tag code know about blogs.
    but the first one will offcourse let the blog know about tags.

    mmm.

    how about this

    BlogPost.find_by_ids(Tag[tag_id].get_items());

     

    I suppose you want to avoid dependencies, and let this appear only when needed. But there is no reason to hide BlogPost and Tag from each other, since they're already bound together in the database schema.

    If you want to keep your classes' code clean and keep it for the real processing, that's a little backwards. These details belongs to classes, not to the higher layers of the application, so it's more readable and more easily testable. I know sometimes we tend to avoid unnecessary indirections, but with proper testing and naming conventions, once you're confident with your classes' methods, you can keep your application code clean and very explicit.

    By the way avoiding classes dependency to keep classes tight is useless in RoR. They couldn't be tighter.

    Say we have 3 tables : posts, posts_tags and tags . Database auto discovery will bind them to classes Post and Tag. No need for PostTag ( if it's purely a link ), as we will declare :

    class Post < ActiveRecord::Base
    has_and_belongs_to_many :tags 
    end

    class Tag < ActiveRecord::Base
    has_and_belongs_to_many :posts
    end

    And that's it, you have your two-way link between your classes, automagically using posts_tags' post_id and tag_id fields. The meaning of find_by_* methods are guessed on-the-fly.

    So it does not take any other programming to use either Post.find_by_tag_id(tag_id) or Tag[tag_id].posts, which yields the same result.



  • @aikii said:

    @stratos said:

    firstly i (almost) totally agree with your post, and guilty as sin i need to write in a language with dollar signs all day. Well what kan i say it's a commercial company and my boss likes money.


    I guess you should be given more credit for keeping things clear when a language doesn't help :) 

    @stratos said:

    but secondly the later will make your Tag code know about blogs.
    but the first one will offcourse let the blog know about tags.

    mmm.

    how about this

    BlogPost.find_by_ids(Tag[tag_id].get_items());

     

    I suppose you want to avoid dependencies, and let this appear only when needed. But there is no reason to hide BlogPost and Tag from each other, since they're already bound together in the database schema.

    I always figured you should decouple stuff when it isn't necisary to do so, so that your code is more re-usable. (read it in "pragmatic programmer" i think)

    if i don't create a specific blog centric tag class, i can do this.

    blogTag = new Tags('blogtag_table');

    photoTag = new Tags('phototag_table');

     
    But perhaps the  cleanest solution is to make a hybrid between this and yours, by putting a decorator pattern in it, to create the blog type specific versions of Tags.

    Also, in my job i'm not allowed to create Oo code, because my boss doesn't like it, so i only know theory and practice and haven't really worked with Oo in a real(tm) project.
     



  • I have to admit I came back to OO just recently. I'm mostly a frustrated PHP guy. It's alright to decouple things but sometimes it comes to absurd abstraction. Recently a friend re-discovered java to make a little GUI. I couldn't help but laugh when I discovered he had to first access the "BorderFactory" to set a border for his panel. That's pushing abstraction a little too far. I guess I'll be flamed for this, but here is where it leads : for the sake of generalization, the simplest and default stuff still needs to dig through deep levels of abstraction.

     About tags : ok, bad example, as a tag has to link to several sources. Coupling Users and Permissions has more sense and could have use that simple structure. In fact there is a plugin called acts_as_taggable ( this is the name of the class property it enables ), which uses a polymorphic link between tags and targets. A tag has several Taggings, and the taggings table has a taggable_id and a taggable_type column, which is really foreign key + table name. Yup, I already hear integrity-purists scream, but it's useful as hell. I'd avoid this kind of stuff when producing reports in pure SQL indeed, but for this kind of use that's really great.
     



  • I'd say make them as long as necessary. I think names should speak fro themselves. I don't see any problem with long names, as auto-completion takes care of that and there are no issues concerning performance either. While I name a variable in a FOR-loop usually "i", I tend to give fields/attributes self explanatory names. It is not a wtf at all.

    I do not use hungarian notation. I do not see really any good use in doing so except if you use a language that handles types rather lax and/or ambiguous like C and such. (I do not mean to bash these languages - just pointing out that this notation is not useful for every language). But even then it can be easily avoided without problem.

    In the end it is just a personal preference you have to find out for yourself. 



  • @aikii said:

    I have to admit I came back to OO just recently. I'm mostly a frustrated PHP guy. It's alright to decouple things but sometimes it comes to absurd abstraction. Recently a friend re-discovered java to make a little GUI. I couldn't help but laugh when I discovered he had to first access the "BorderFactory" to set a border for his panel. That's pushing abstraction a little too far. I guess I'll be flamed for this, but here is where it leads : for the sake of generalization, the simplest and default stuff still needs to dig through deep levels of abstraction.

    Most likely the reason for that is optimization: It's relatively common to have quite a lot of UI elements with the same border style; since Border objects are immutable, the border factory can easily return the same border object whenever the application asks for a lowered pink-cyan border. Another important issue is speed; the factory can deliver an instance of a class that draws the requested kind of border without going through a lot of ifs.



  • @ammoQ said:

    Most likely the reason for that is optimization: It's relatively common to have quite a lot of UI elements with the same border style; since Border objects are immutable, the border factory can easily return the same border object whenever the application asks for a lowered pink-cyan border. Another important issue is speed; the factory can deliver an instance of a class that draws the requested kind of border without going through a lot of ifs.

    I agree with the fact that such a system is available. The real WTF, if I may, is that it's mandatory, and I wonder if such an optimization couldn't happen transparently for the default case.

    I guess the many verbose features like this in java exists to force a certain programming style. Back in '97, when I opened my first java book, I was delighted, mostly by how easy threads and network programming were. But right now I'd stay away from it.



  • @aikii said:

    @ammoQ said:

    Most likely the reason for that is optimization: It's relatively common to have quite a lot of UI elements with the same border style; since Border objects are immutable, the border factory can easily return the same border object whenever the application asks for a lowered pink-cyan border. Another important issue is speed; the factory can deliver an instance of a class that draws the requested kind of border without going through a lot of ifs.

    I agree with the fact that such a system is available. The real WTF, if I may, is that it's mandatory, and I wonder if such an optimization couldn't happen transparently for the default case.

    I wonder how you could do the optimization transparently, using the existing language elements in Java...



  • @ammoQ said:

    I wonder how you could do the optimization transparently, using the existing language elements in Java...

    He, I don't know. Supposedly, Sun doesn't want such a feature at all.



  • @Skurry said:

    Personally, I like the idea of naming variables according to their lifespan and importance.

    I agree completely, and I especially think that this rule should extend to the database.  Your tables have the longest lifespan of any object, are arguably the most important, and therefore should have highly descriptive names.
     



  • @aikii said:

    @ammoQ said:

    Most likely the reason for that is optimization: It's relatively common to have quite a lot of UI elements with the same border style; since Border objects are immutable, the border factory can easily return the same border object whenever the application asks for a lowered pink-cyan border. Another important issue is speed; the factory can deliver an instance of a class that draws the requested kind of border without going through a lot of ifs.

    I agree with the fact that such a system is available. The real WTF, if I may, is that it's mandatory, and I wonder if such an optimization couldn't happen transparently for the default case.

    The usage of BorderFactory is not actually mandatory. You are free to instantiate Border subclasses directly. It's just not very good programming.

    The BorderFactory class is in fact the optimization you mention, of course, and I don't think I'd want it to be transparent. When I write 'new JLabel' I expect an object to be created. I don't think I'd care for a language where sometimes "new" means "a new instance" and sometimes it means a cached or interned instance. Sounds like a recipe for headaches.



  • @Phalphalak said:

    I don't see any problem with long names, as auto-completion takes care of that

    It's not a matter of writing. Yes, you have auto-complete for that.

    Too-long names can be a problem/annoyance when reading the code.

     



  • @dhromed said:

    @Phalphalak said:

    I don't see any problem with long names, as auto-completion takes care of that

    It's not a matter of writing. Yes, you have auto-complete for that.

    Too-long names can be a problem/annoyance when reading the code.
     

    I'd rather want to read code with too long variable names than code with too short variable names.

    Of course you can always pervert the idea by using very similar variable names like "IndexFromTheTable" and "IndexForTheTable"  in the same program.
     

     



  • @ammoQ said:

    @dhromed said:
    @Phalphalak said:

    I don't see any problem with long names, as auto-completion takes care of that

    It's not a matter of writing. Yes, you have auto-complete for that.

    Too-long names can be a problem/annoyance when reading the code.
     

    I'd rather want to read code with too long variable names than code with too short variable names.

    Of course you can always pervert the idea by using very similar variable names like "IndexFromTheTable" and "IndexForTheTable"  in the same program. 

    It depends, of course, where you set the limit.

    indexOfSupplyTable is not too long.

    rawDataStorageBinding is not really too long.

    But longer than that becomes annoying.

    iSupTabl and rdStorBind would be really, really bad varnames.
     



  • @dhromed said:

    It depends, of course, where you set the limit.

    indexOfSupplyTable is not too long.

    rawDataStorageBinding is not really too long.

    But longer than that becomes annoying.

    iSupTabl and rdStorBind would be really, really bad varnames.
     

    I agree long variable names are annoying, but what do you do with properties like the following

    bool HasPreformTransferArticulatingArms

    bool HasBottleTransferArticulatingArms

    IMO, those stretch the limits but I really can't think of a good way to shorten them.  I could make a Transfer class and assign a BottleTransfer and PreformTransfer property to the parent.  That seems like going overboard when the only property on them is whether they have articulating arms or not.  If I were tracking more Transfer attributes, I would go with the class option.

     



  • @jergosh said:

    I recently had a bit of, erm, heated discussion over variable naming in my programming assignment. I followed the standard naming convention of calling an int 'i',  a char 'c', position in line 'pos' etc. but was told to change them to ForLoopCounter, InputCharacter and PositionInLineFromLeftSide respectively (on may say wtf?!). Could anybody please point me to some books on the style of programming where using overly long var names is explicitly discouraged?
    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++)

    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.

    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.

    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.



  • @xtremezone said:

    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.

    Please, for the love of all that is decent and holy, or for the love of whatever unholy demons you might worship, STOP PERPETUATING PSEUDO-HUNGARIAN!

    VB.NET is *very* typesafe. There is no need to embed the type in the variable name, you *know* the type when you declare it! If you need to embed *purpose* in the variable name (the *correct* way to use hungarian notation) use a *postfix* not a prefix!

    I agree that 'i' might not be immediately recognized by VB developers, since they rarely come from a C background, but in that case 'index' (or 'Index') is perfectly acceptable.

    'intIndex' is *not*. It breaks autocomplete and just plain looks silly. What is the purpose of VB if not Rapid Application Development?



  • @Whiskey Tango Foxtrot? Over. said:

    Please, for the love of all that is decent and holy, or for the love of whatever unholy demons you might worship, STOP PERPETUATING PSEUDO-HUNGARIAN!

    VB.NET is *very* typesafe. There is no need to embed the type in the variable name, you *know* the type when you declare it! If you need to embed *purpose* in the variable name (the *correct* way to use hungarian notation) use a *postfix* not a prefix!

    I agree that 'i' might not be immediately recognized by VB developers, since they rarely come from a C background, but in that case 'index' (or 'Index') is perfectly acceptable.

    'intIndex' is *not*. It breaks autocomplete and just plain looks silly. What is the purpose of VB if not Rapid Application Development?

    Yes, Twisted Hungarian in strongly typed languages isn't the best practice at all.

    For my sins however, I do use the e.g. txtFirstName naming convention in UI stuff (windows & web) purely because it makes intellisense group controls together by type.



  • I concur; in fact I would argue that UI coding ends up more unreadable if you avoid hungarian than if you use it.  My convention is to append the type of UI control to the information it displays: i.e. employeeIDTextBox.  

    There are situations in which having the type of an object in its name is useful for a variety of reasons.  For example, I had a boss who would not allow database column names like 'createdDate' because that was too close to Hungarian.  Clearly though, if you have a DB column that is just called 'created' it will seem to be a boolean.  We ended up with names like 'whenCreated' (which suffers from the same "problem" as 'createdDate' in my opinion, but it appeased the boss).  But the lesson is that you simply have to indicate the type of the column somehow.

    Another example is data structures.  Lets say you have a list of employee objects.  You could call the container for them "employees", but if you're reading quickly, the 's' is easy to miss.  A better name is employeeList.  If it's a hashtable, employeeHash is a helpful name.

    Finally, if you have to remember something about an item every single time you use it, the name is a helpful tool to do that.  Joel gives another example from UI coding: preventing xss attacks.  If you have some data that needs to have html escaped before it is written to the page, giving it a name prefixed with "unsafe" can keep you from making a big mistake.

    While I'm not trying to say that every variable in your program needs to have a name like this, there are times when it is helpful.  Don't let your language zealotry take a useful tool out of your toolbox.



  • @rmr said:

    I concur; in fact I would argue that UI coding ends up more unreadable if you avoid hungarian than if you use it.  My convention is to append the type of UI control to the information it displays: i.e. employeeIDTextBox

    That's not Hungarian notation, that's a relatively descriptive variable name. The pseudo-Hungarian aberration would be something like "crtbEmployeeID" where the Hungarian is "const reference textbox".



  • @RayS said:

    For my sins however, I do use the e.g. txtFirstName naming convention in UI stuff (windows & web) purely because it makes intellisense group controls together by type.

    The best thing I've found for this is to use "ui" as a prefix for all UI controls.  Besides underscores for private variables, this is the only prefix I use in VB.NET.

    The "ui" is nice because that way all of your UI controls are grouped together in one place in the massive Intellisense Form members list.  I also always put some kind of indication of what type of control it is in the name.  So for example, I might have uiUserNameLabel and uiUserNameTextBox, which show up next to each other in the list.

    I think the normal way of doing it (txt,lbl,etc.) is annoying because you have to agree on a standard list for all controls, even the obscure and custom ones.  Even for the more common ones, some people tend to use "cbo" for combo boxes, but other people use "cmb" or even "cbb".  But by far the most annoying naming system is the "default" one (TextBox1,TextBox2,etc.).



  • @Mikademus said:

    @rmr said:

    I concur; in fact I would argue that UI coding ends up more unreadable if you avoid hungarian than if you use it.  My convention is to append the type of UI control to the information it displays: i.e. employeeIDTextBox

    That's not Hungarian notation, that's a relatively descriptive variable name. The pseudo-Hungarian aberration would be something like "crtbEmployeeID" where the Hungarian is "const reference textbox".

    Yeah, it isn't exactly hungarian, but the criticism I was responding to was:

    @Whisky Tango Foxtrot? Over said:


    Please, for the love of all that is decent and holy, or for the love
    of whatever unholy demons you might worship, STOP PERPETUATING
    PSEUDO-HUNGARIAN!

    VB.NET is *very* typesafe. There is no need to embed the type in the variable name, you *know* the type when you declare it!

    I suppose I should have quoted that in my original response.



  • @rmr said:

    Yeah, it isn't exactly hungarian, but the criticism I was responding to was:

    @Whisky Tango Foxtrot? Over said:


    Please, for the love of all that is decent and holy, or for the love of whatever unholy demons you might worship, STOP PERPETUATING PSEUDO-HUNGARIAN!

    VB.NET is *very* typesafe. There is no need to embed the type in the variable name, you *know* the type when you declare it!

    I suppose I should have quoted that in my original response.

    I would argue that you and I actually agree. Every example you gave embedded purpose in the name as a postfix, just as my next sentence -- you know, the one you didn't quote -- suggested. Here, I'll quote it for you:

    @Whiskey Tango Foxtrot? Over. said:

    If you need to embed *purpose* in the variable name (the *correct* way to use hungarian notation) use a *postfix* not a prefix!

    When it comes to UI controls, it's very often a good idea to include that its purpose is to be a TextBox control, or a Label. It just happens that the name of the class correspond to the purpose in your examples.


Log in to reply