Hungarian Notation Gone Too Far



  • There are a very few, very specific, very isloated circumstances when I use Hungarian notation.  Beyond those few, I hate that scheme with the white-hot intensity of five suns.

    But, I'm a contractor... I hop from gig to gig, and I see all sorts of conventions, and Hungarian pops up a lot.  So, I go with the flow, "When in Rome" and all that.

    My most recent Hungarian client really drove me nuts.  All the fields in every database table are helpfully prefixed with "fld"... you know... so you realize they're fields and not... well... I'm not sure what else they might be... but at least there's no confusion!

    Imagine...

    SELECT fldFirstName, fldLastName FROM tblCustomers WHERE fldID=@ID
    SELECT fldComments, fldCommentDate FROM tblRecommondations WHERE fldCompletedDate IS NULL


  • My personal favourite involved using numbers to identify table names and "Hungarianing" each column with that number.

    For example, a relatively sane applications may have a table like this:

    Table: Product

    ProductId

    ProductName

    etc.

     

    This application would instead define:

    Table: 104_Product

    104_ProductId

    104_ProductName

    And the magic numbers were unique within the database, so if you had another table called 107_Order, it would contain a 107_OrderId and a 104_ProductId although really because the type of people they were, they'd instead just call the columns 107_Id and 104_Id.

    And table 203_CustomerOrder might have a 203_Id and 107_Id (for example). This got really fun when the designers figured out the R in RDBMS and discovered the magic of normalization.

    There were around 200 tables in the DB and each developer needed to basically maintain a mental lookup table of numbers to actual table names to make sense of even the most trivial query.


     


     



  • Not everything that a query returns comes from a "field" (or as I would call it, a "column") -- you could also have the output of a function, or the current value of a sequence, or an aliased literal value, etc.

     Nor is it necessarily redundant for the table name to be Hungarianized -- calling it "tblFoo" indicates that the relation is a physical table, and not a view, or a named subquery, or...

     But if Hungarian notation is truly necessary, I see no need for the prefixes to be three letters long.  "cFoo" for a column and "tBar" for a table should be more than sufficient.



  • As Rootbeer pointed out, sometimes it's handy. I use notation on the parent sources (tables, views, sprocs, functions), including inside sprocs themselves.. but I don't use them on the columns/fields. The only thing I may do to fields is use an alias (AS) to prevent conflict or provide a name that's more suitable for the current context. Appending "fld" to every single column is absurd.


  • Discourse touched me in a no-no place

    @Rootbeer said:

    Nor is it necessarily redundant for the table name to be Hungarianized -- calling it "tblFoo" indicates that the relation is a physical table, and not a view, or a named subquery, or...
    The following assumes that Hungarian notation for databases is a sensible thing to do. IMO it isn't:

    Hungarian notiation is not prefixing names with the physical type of what's being represented, it's to indicate what sort of object is being represented.

    To use your example, a table and a view may legitimately have the same prefix, despite being physically represented in different forms.

    For example what happens when a table gets normalised to two new tables and a view is created to replicate the, now missing, table? Do you go round search/replacing through all your source code?

    This is the same idiocy that results in misnamed 'hungarian' variables in source code:

    <font face="courier new,courier">int iVariable; // what happens when the type changes to long? or double? </font>



  • I'm sick of the Hungarian notation debates.  Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?



  • @PJH said:

    Hungarian notiation is not prefixing names with the physical type of what's being represented, it's to indicate what sort of object is being represented.

    So it might be sensible to label the columns as 'ageVoting', 'ageDrinking', (for the resp. legal voting and drinking ages of a country), next to 'nrofpeopleCountry', 'nrofpeopleCapital' (for the number of people in resp the entire country or just the capital), while they are all 'fields' and probably all ints.


  • @bstorer said:

    I'm sick of the Hungarian notation debates.  Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

     definitely camelCasing, less characters to type and I don't have to my fingers out of their comfort zone like I do to type an _



  • @campkev said:

     definitely camelCasing, less characters to type and I don't have to my fingers out of their comfort zone like I do to type an _

     

    Camel casing has it's place as well as other conventions. You cannot just say camel casing for everything.

    camelCasing should be used for parameters.

    PascalCasing should be used namespace, type, and member names (just about everything else really). 




  • @campkev said:

    @bstorer said:

    I'm sick of the Hungarian notation debates.  Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

     definitely camelCasing, less characters to type and I don't have to my fingers out of their comfort zone like I do to type an _

     

    I would assume most programmers feel the same way.  Why, then, do both Ruby and Python go_with_underscores? 



  • @bstorer said:

    I would assume most programmers feel the same way.  Why, then, do both Ruby and Python go_with_underscores?

    Old school habits, perhaps? I don't know who was involved in creating the languages, but the practices used tend to come from the creators... just like all the damn "myVariable" declarations in .NET I keep seeing. Microsoft started that by putting it in the MSDN examples. Sometimes I'm so tempted to randomly change them to "your" and "our" and commit back to SVN.

    In C#, I use camelCase for local and private variables as well as parameters. I was using it for private method declarations, but then it started looking too weird to me. So, all methods are declared with PascalCasing (as MPS put it).



  • @AbbydonKrafts said:

    In C#, I use camelCase for local and private variables as well as parameters. I was using it for private method declarations, but then it started looking too weird to me. So, all methods are declared with PascalCasing (as MPS put it).
     

    Wrong, please use the standard conventions. I said:

    camelCasing should be used for parameters.

    PascalCasing should be used namespace, type, and member names (just about everything else really).

    EDIT: I recommend you read http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756

     



  • @campkev said:

     definitely camelCasing, less characters to type and I don't have to my fingers out of their comfort zone like I do to type an _

     

    or use dvorak, the _ is next to the 'enter', where the ' is on querty. Of course dvorak is much better suited for python than for C, because the {} are moved to the -= on the top row. It is still one keystroke more than camelCasing.



  • @MasterPlanSoftware said:

    Wrong, please use the standard conventions. I said:

    camelCasing should be used for parameters.

    PascalCasing should be used namespace, type, and member names (just about everything else really).

    EDIT: I recommend you read http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756

    I should've just left out my note. I meant the "PascalCase" reference you made (I never heard anyone else refer to it that way before). I use camelCasing for local and private variables for visual purposes. Since they are not being used outside of the class, it shouldn't matter. Likewise, I refer to class-level variables with "this." so that I can quickly tell the scope (without the Hungarian "m" notation).

    I have a hard time following any design book, especially those published by Microsoft. They all contradict each other and change their minds year over year. Also, I don't have $36 to drop on a book right now.



  •  @bstorer said:

    I'm sick of the Hungarian notation debates.  Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

     

    Can I get a shout-out for SpectateSwamp's SylLaBle variation of camelCasing?

     



  • @AbbydonKrafts said:

    I meant the "PascalCase" reference you made (I never heard anyone else refer to it that way before).
     

    http://blogs.msdn.com/brada/archive/2004/02/03/67024.aspx

    http://msdn2.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx

    http://msdn2.microsoft.com/en-us/library/ms229043.aspx

    http://cplus.about.com/od/learnc/ss/csharpclasses_5.htm

    @AbbydonKrafts said:

    I use camelCasing for local and private variables for visual purposes

    For the sake of everyone else, and standards, stop it.

    @AbbydonKrafts said:

    Since they are not being used outside of the class, it shouldn't matter.

    I am sure there is no chance of any other programmer ever having to read or modify that code.

    @AbbydonKrafts said:

    Likewise, I refer to class-level variables with "this." so that I can quickly tell the scope (without the Hungarian "m" notation).

    You wouldn't have to do either of these things if you followed the case standards.

    @AbbydonKrafts said:

    I have a hard time following any design book, especially those published by Microsoft.

    It is published by Addison Wesley.

    But I can understand why you wouldn't want to listen to anything MS says about the technologies they developed... </sarcasm>

    @AbbydonKrafts said:

    They all contradict each other and change their minds year over year.

    No they don't. These standard are based on the internal standards they developed when they wrote the framework.

    @AbbydonKrafts said:

    Also, I don't have $36 to drop on a book right now.

    There are these things called libraries... 

     

     

     

     

     



  • @MasterPlanSoftware said:

    I didn't say you came up with it. I just said you mentioned it and that I had never seen it put that way before. I didn't need proof that others call it that.

    @MasterPlanSoftware said:

    For the sake of everyone else, and standards, stop it.

    You're acting like I name all of my variables "a", "aaaa", "b1sd" and such without a single comment line.

    @MasterPlanSoftware said:

    I am sure there is no chance of any other programmer ever having to read or modify that code.

    The general consensus in this office, and I have been told as such by my supervisor, is that I create the cleanest and most well-commented code out of the group. So, if my style is so horrible, how come it's the best out of the group?

    @MasterPlanSoftware said:

    You wouldn't have to do either of these things if you followed the case standards.

    So by declaring all variables with PascalCase, I'll be able to tell if the variable came from the class level or local to the procedure. Exactly how is that? The only thing it allows me to do is differentiate between local variables and parameters, which is less of a problem to me than local and class-level. I don't see how matching the case for these two would help out any.

    @MasterPlanSoftware said:

    It is published by Addison Wesley.

    But I can understand why you wouldn't want to listen to anything MS says about the technologies they developed...

    Technicality. The book was written by Microsoft employees using internal documentation. And I've already covered why Microsoft documentation on their own technologies has a problem: They started the whole "my" notation by including it in their examples. Also, they can't even keep MSDN straight.

    @MasterPlanSoftware said:

    No they don't. These standard are based on the internal standards they developed when they wrote the framework.

    And since when are private variables so important in the broad scope of things? I really don't know why you are getting worked up over them. I already said that all of the other declarations are camelCase (parameters) or PascalCase (everything else).

    @MasterPlanSoftware said:

    There are these things called libraries...

    The gas and time it would take me to find a library that actually stocks technology books, especially up-to-date ones, would cost more than the books themselves. This isn't exactly a big city with a fully-stocked library. I think the entire non-fiction section could fit in a 53' transfer truck. It probably wouldn't even take that much.



  • use the standard for whatever language you are using.  You can use whatever casing scheme you think is best when you bother to make your own language. 



  • @Rootbeer said:

    Not everything that a query returns comes from a "field" (or as I would call it, a "column") -- you could also have the output of a function, or the current value of a sequence, or an aliased literal value, etc.

     Nor is it necessarily redundant for the table name to be Hungarianized -- calling it "tblFoo" indicates that the relation is a physical table, and not a view, or a named subquery, or...

     

     

    We have a winner.

    Would you rather have Field1, Field2, Field3, Field4 in Table1, Table2, Table3? 



  • @AbbydonKrafts said:

    The general consensus in this office, and I have been told as such by my supervisor, is that I create the cleanest and most well-commented code out of the group. So, if my style is so horrible, how come it's the best out of the group?

    I would say it doesn't say much about the rest of your group. But what I am saying has nothing to do with 'clean' or 'most well-commented code'. Use the standards. Simple as that.

    @AbbydonKrafts said:

    So by declaring all variables with PascalCase, I'll be able to tell if the variable came from the class level or local to the procedure. Exactly how is that? The only thing it allows me to do is differentiate between local variables and parameters, which is less of a problem to me than local and class-level. I don't see how matching the case for these two would help out any.

    I use PascalCasing for them all, and with any class level private members, I simply prefix it with an underscore. Simple, and conforms.

    @AbbydonKrafts said:

    Technicality. The book was written by Microsoft employees using internal documentation.

    So what? I cannot think of any place you are going to find a more informed set of people on .NET than the people who architected it.

    @AbbydonKrafts said:

    And I've already covered why Microsoft documentation on their own technologies has a problem: They started the whole "my" notation by including it in their examples. Also, they can't even keep MSDN straight.

    That is a ridiculous argument. They surely expect that the programmer using the example would be intelligent enough to write their own code... Anyone who prefixes all their variables with 'My' is just incredibly stupid. That has nothing to do with MSDN.

    Besides all that, finding someone who doesn't use a standard doesn't give you any excuse to also not follow the standard.

    @AbbydonKrafts said:

    And since when are private variables so important in the broad scope of things?

    Casing has nothing to do with importance.

    @AbbydonKrafts said:

    The gas and time it would take me to find a library that actually stocks technology books, especially up-to-date ones, would cost more than the books themselves. This isn't exactly a big city with a fully-stocked library. I think the entire non-fiction section could fit in a 53' transfer truck. It probably wouldn't even take that much.

    Right. So you refuse to learn things based on excuses like "I have no money" "it is too far". Awesome.

    The link I already posted: http://msdn2.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx

    Has the same rules spelled out in a nice table. But I know the effort to visit the site is too much. 



  • I'm not even going to start going in circles with this. Instead, can you explain why the private class-level variables in the Field Usage Guidelines are camelCased?



  • @AbbydonKrafts said:

    I'm not even going to start going in circles with this. Instead, can you explain why the private class-level variables in the Field Usage Guidelines are camelCased?
     

    Because they had someone like you who is too cool to listen to standards write the example?



  • @MasterPlanSoftware said:

    Because they had someone like you who is too cool to listen to standards write the example?

    So now you are contradicting yourself by saying to look at the MSDN, but don't believe it.

    @Field Usage Guidelines said:

    Do not use uppercase letters for field names.

    @Field Usage Guidelines said:
    Do not apply a prefix to field names or static field names.

    Those two documented instructions (not just code samples) state to use camelCase and no underscores and the like. That's completely opposite to what you say the standards are (PascalCase with a leading underscore).

    I told you it's contradicting. Since I don't buy books, I use the MSDN as my reference. It's the one completely accessible resource to anyone. According to this particular entry, I'm declaring my variables just fine.



  • @bstorer said:

    Why, then, do both Ruby and Python go_with_underscores?

    Because camel case fails in the presence of acronyms. Consider something like CORBAXMLWWWWrapper. Camel case is ambiguous, underscores are not.



  • @asuffield said:

    @bstorer said:

    Why, then, do both Ruby and Python go_with_underscores?

    Because camel case fails in the presence of acronyms. Consider something like CORBAXMLWWWWrapper. Camel case is ambiguous, underscores are not.

     

    Yes, but the underscore key is all the way up there (I am now pointing at the top right of the main body of keys).  it_really_sucks_because_thats_a_pinky_key.  thisIsFarEasierForMe (maybeBecauseImLeftHanded?).



  • @emurphy said:

     @bstorer said:

    I'm sick of the Hungarian notation debates.  Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

    Can I get a shout-out for SpectateSwamp's SylLaBle variation of camelCasing?

    ShoutOut For The ClueLess! 



  • @bstorer said:

    Can't we argue something else, like camelCasing versus
    using_lowercase_and_underscores?

    howaboutlowercaseandnounderscoresmuchmuchlesstypingthisway.



  • @Spectre said:

    @bstorer said:
    Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

    howaboutlowercaseandnounderscoresmuchmuchlesstypingthisway.

     

    thisisactuallyprettycommoninpythonfunctionnames 



  • @bstorer said:

    @Spectre said:

    @bstorer said:
    Can't we argue something else, like camelCasing versus
    using_lowercase_and_underscores?

    howaboutlowercaseandnounderscoresmuchmuchlesstypingthisway.

     

    thisisactuallyprettycommoninpythonfunctionnames 

    It's a Lua thing, too. wheninrome, right?



  • I recently worked on a project that had a bunch of stuff defined like this (language and context anonymized):

    [code]MyUserDefinedControlWithInsanelyLongNameThatPartiallyDescribesWhatItDoes ctlMyUserDefinedControlWithInsanelyLongNameThatPartiallyDescribesWhatItDoes1 = new MyUserDefinedControlWithInsanelyLongNameThatPartiallyDescribesWhatItDoes();[/code]

     



  • @bstorer said:

    Can't we argue something else, like camelCasing versus using_lowercase_and_underscores?

    typedef struct _CastInTheNameOfGod *ye_not_guilty_t; // :-)



  • @bstorer said:

    it_really_sucks_because_thats_a_pinky_key

    I hit it with my middle finger, never really found it difficult. 



  • @bstorer said:

    I would assume most programmers feel the same way.  Why, then, do both Ruby and Python go_with_underscores? 

     

    I don't know about Python, but Ruby does it because the guy who created it is Japanese, and seperating words with underscores made it easier for him and other Japanese programmers to read.

     

    which_I_guess_makes_sense_as_this isMuchEasierToReadThanThis 



  • @AbbydonKrafts said:

    @MasterPlanSoftware said:
    Because they had someone like you who is too cool to listen to standards write the example?
    So now you are contradicting yourself by saying to look at the MSDN, but don't believe it. @Field Usage Guidelines said:
    Do not use uppercase letters for field names.
    @Field Usage Guidelines said:
    Do not apply a prefix to field names or static field names.

    Those two documented instructions (not just code samples) state to use camelCase and no underscores and the like. That's completely opposite to what you say the standards are (PascalCase with a leading underscore).

     

    I told you it's contradicting. Since I don't buy books, I use the MSDN as my reference. It's the one completely accessible resource to anyone. According to this particular entry, I'm declaring my variables just fine.

     

    Fisted.



  • Notation standards?  Who cares what the experts say?

    Use the standard adopted by your current employeer, which may be different from your previous employeer, but may have some basis in the many variants of standards published.  The important part is that everyone tries to use the same standard on the same project.  If your place doesn't have a standard try to establish one by using all the resources out there and picking one which best fits how your shop works.

     

    As far as hungarian in databases, I only have one place I do this.  I will always prefix my views with v, only to separate from from actual tables.  This lets me know that the select target is not really a table and is doing other things under the hood which can have an impact on performance and/or results.  stored procs should have a verb (get, save, update), tables are just describing what they hold, and columns are self explainatory as they are the containers for the different data elements.  So yes, I kinda use hungarian in mydatabase structure, but only to denote views as opposed to tables.



  • @ObiWayneKenobi said:

    which_I_guess_makes_sense_as_this isMuchEasierToReadThanThis 
     

    It is.  I understand the less-typing argument, but I honestly don't see why namingVariablesAndFunctionsLikeThis became the thing to do, when this_looks_so_much_more_like the written language we use to communicate with other humans and which most of us learn first.

    It should be noted that printed characters frequently run together in my head (some mild kind of dyslexia, maybe? dunno).



  • @KattMan said:

    I will always prefix my views with v, only to separate from from actual tables.

    I prefix my views with "WTFDidYouDoThatFor", for the same reason.



  • @MasterPlanSoftware said:

    Because they had someone like you who is too cool to listen to standards write the example?
     

     Variable naming conventions aren't standards -- they are conventions.   No compiler warnings are generated if I use the "wrong" capitalization.




  • @Rootbeer said:

     Variable naming conventions aren't standards -- they are conventions. 
     

    Agreed. Convention would have been better wording in hindsight.



  • @MasterPlanSoftware said:

    @AbbydonKrafts said:

    I use camelCasing for local and private variables for visual purposes

    For the sake of everyone else, and standards, stop it.

     <hints id="hah_hints"></hints>
    I hate to break it to you, but that [B]is[/B] the standard.  You cite the [URL=http://msdn2.microsoft.com/en-us/library/ms229043.aspx]Capitalization Conventions[/URL].  It says, and I quote (emphasis mine):

    Do use Pascal casing for all [B]public[/B] member, type, and namespace names consisting of multiple words.

     

     

    It's not clear on private fields or local variables.  There is another document explaining that, which is the [URL=http://msdn2.microsoft.com/en-us/library/ta31s3bc(VS.71).aspx]Field Usage Guidelines[/URL].  I'm not going to quote that, since it's pretty clear with examples and everything. 

    The actual guidelines, according to both the Microsoft conventions and the earlier Philips conventions, if you want to follow them, are:

    - All namespaces are PascalCase, regardless of protection level. 

    - All type names are PascalCase.

    - All methods are PascalCase.

    - All other [B]public[/B] and [B]protected[/B] type members (events and properties, don't use public/protected fields) are PascalCase.

    - Parameters, local variables, and private instance fields are camelCase.

     

    If you're going to be a jackass, at least be right. 



  • OK, I missed the quote above where somebody already made that point.  Sorry for the redundancy. 

    <hints id="hah_hints"></hints>


  • @untalented_newbie said:

    I understand the less-typing argument, but I honestly don't see why
    namingVariablesAndFunctionsLikeThis became the thing to do, when
    this_looks_so_much_more_like the written language we use to communicate with
    other humans and which most of us learn first.

    I know. Let's just separate the name components with spaces because that's how human languages work. Pity that we'll have to switch to Tcl for that, though.



  • I fail to see why it matters.  Every organisation is going to have it's own standards or conventions, and guidelines are just guidelines, not some set of HOLY RULES written in twelve foot high letters of fire.

    The important thing is that you're consistent within the standards or conventions of where you work, and if you can't adapt within a day or so, you're not really in the right job, are you? 



  • Oh and for hungarian in stored procs...

    Never, and I mean NEVER, prefix your procs with sp_.  If you have to ask why, stop writing procs. 



  • @Spectre said:

    I know. Let's just separate the name components with spaces because that's how human languages work.
     

    Regrettably, I don't know Tcl, so I don't know if you're taking a sarcastic jab or not here, but if so, I'd counter with the idea that anything that even remotely enhances code clarity and makes it faster and easier to read and absorb (and by extension, faster and easier to maintain) is worth a little extra typing (and yes, I know all human written languages don't have the same spacing rules the European-origin ones do).

    And to go back to the OP's topic, Hungarian notation is pure, unholy, absolute evil and doesn't really seem to add any information that one couldn't already understand from the name of the variable (if one chooses good variable names, anyway). I especially love when people do stuff like lplpddsMainDrawSurface (I seem to recall seeing a variable name almost exactly like this at a previous employer).  Seven characters, and we haven't even hit the actual name of the item yet!  People familiar with the code would be able to guess that, with a name like MainDrawSurface, in a Win32 project, it's probably a directdraw surface, making ddsd unneeded.  'lplp' almost makes sense - remembering the correct level of pointer indirection is important - but I'm pretty sure there isn't a distinction between short pointers and long pointers anymore (I might be wrong about this, maybe it still matters if you're making calls to functions in 16-bit dlls?), so 'pp' is probably a better choice.


  • Discourse touched me in a no-no place

    @untalented_newbie said:

    And to go back to the OP's topic, Hungarian notation is pure, unholy, absolute evil and doesn't really seem to add any information that one couldn't already understand from the name of the variable (if one chooses good variable names, anyway).
    I take it you haven't read http://www.joelonsoftware.com/articles/Wrong.html yet?



  •  You got me there.  I meant Systems Hungarian, not Apps Hungarian (see previous comment about good variable names).  I don't follow Simonyi's format, but I do agree with the idea of having certain name conventions for certain kinds of item (like ending index or counter variables with _idx, for example).



  • Systems can be useful as a form of self-documentation in certain limited cases (the table vs. view example springs to mind, where it's easy to see the type in your database management software, but not so much in your code), and I religiously use it for controls as an aid to intellisense, but otherwise it's horrible.  Just look at Direct X, probably the worst offender.



  • @PJH said:

    @untalented_newbie said:

    And to go back to the OP's topic, Hungarian notation is pure, unholy, absolute evil and doesn't really seem to add any information that one couldn't already understand from the name of the variable (if one chooses good variable names, anyway).
    I take it you haven't read http://www.joelonsoftware.com/articles/Wrong.html yet?

    I was just discussing this on slashdot. My point was that ultimately, since the prefixes are so informative with regards to "functional typing" (typing in terms of function, or more generally, typing in terms of the extension of an arbitrary predicate), the prefix should be the entire variable name. Any root + suffix is redundant. This, of course, is assuming that you choose a relevant and useful prefixing scheme.

    I mean, sure, you might have a temperature type, and its prefix might be 'temp'. But what are you going to call an actual temperature instance variable? temp_temp? That's obviously redundant. temp_unprocessed (in the case that it's unprocessed)? Fine, but it's in a weird word order with respect to English, where adjectives usually go first. I'd much rather see "adj + type" constructions, like "unprocessedTemp", "unprocessedTemps" (for collections of temps) and the like. Of course, if temp is a type, then unprocessedTemp is a de facto subtype, both conceptually and linguistically.



  • @untalented_newbie said:

    Regrettably, I don't know Tcl, so I don't know if you're taking a sarcastic
    jab or not here, but if so, I'd counter with the idea that anything that even
    remotely enhances code clarity and makes it faster and easier to read and absorb
    (and by extension, faster and easier to maintain) is worth a little extra typing
    (and yes, I know all human written languages don't have the same spacing rules
    the European-origin ones do).

    I mentioned Tcl because it is the only language I can remember of that permits any character in variable names, except closing brace. As for readability, you judge:

    set {The Daily WTF memes} {{Paula Bean} {No quack} {Wooden table} {Desktop Search} {Tag abuse}}
    
    puts "We've got a lot of memes: at least [llength ${The Daily WTF memes}]!"
    

    Note: I don't know whether this works, since I don't have an interpreter handy.


Log in to reply