Thanks everyone for your thoughts, very enlightening as always! My overiding concern is readability, and as some of you have pointed out HN is about as readable as well... Hungarian probably! :-)
At times there is some utility in knowing the data type of a variable (hence my fondness for qryGetAllWidgets) but it's by no means a constant need and in such cases there are better ways of signifying the data type than the use of abbreviation prefix - customerArray has got to be better than arr_customer surely! I did some more digging around on this, and read Joel's article again (http://www.joelonsoftware.com/articles/Wrong.html) and concluded the "unsafeName" and "safeName" (or following Barney's suggestion unsafe.Name and safe.Name) have got to be more meaningful than "usNAme" and "sName". I also read the wikipedia article on HN (http://en.wikipedia.org/wiki/ Hungarian_notation) where I found this quote attributed to Linus Torvalds "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged". Good old Linus, another measured contribution to the debate. On Sep 17, 9:24 pm, "Nolan Erck" <[EMAIL PROTECTED]> wrote: > I find I'm in the minority with this, but I use some variant of HN on nearly > all my projects. I originally came from a C++ world (working on video > games) and it was used heavily on those projects. Nowadays, even when I > work with ColdFusion, I find the visual reminder of the data type to be very > helpful. > > If I use HN, I'm guaranteed not to use a reserved word as a variable name by > accident (see Ray Camden's blog post a few months back). > > If I have to deal with files that are incredibly long, I may not see the > initial (for example) CFQuery, or ArrayNew() or other "clue" as to what the > data type is. Without scrolling up to the top of the screen (and losing my > place), I may have no idea what "foo" is storing (okay, I may have SOME > idea, but I'm still having to do a bit of guess work). But if it's > "arrFoo", I know it's an array; "qryFoo" is probably a query and "pFoo" is > probably a pointer (as was the convention I used in C++ for pointers). > > Quick! What's the variable "User" storing? An object? A struct? A string? > There's no way to tell without looking at other code. Now, what's "strUser" > storing? > > (Joelonsoftware.com has a great article on naming conventions, prefixing > variables based on if they're safe (i.e. the data has been tested), or > unsafe (just submitted by an unknown user via a web form) and so on. It's > well worth reading.) > > 2 cents. > > -nolan > > On Wed, Sep 17, 2008 at 5:51 PM, Alan Livie <[EMAIL PROTECTED]> wrote: > > My pet hate is cfc METHODS with fn in front of the method name. > > > I admit to the occasional lapse with HN. We use it as a coding standard for > > a company I work for and it has bled into other projects for other clients > > but I'm working on it :-) > > > I spend so much time making my unit tests test method names read like > > English then lapse in my actual code and do things like bIsAdministrator ... > > DOH! > > > Alan > > > ----- Original Message ---- > > From: Sammy Larbi <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, September 17, 2008 5:21:12 PM > > Subject: [CFCDEV] Re: Hungarian notation is for numpties - discuss! > > > On Wed, Sep 17, 2008 at 5:03 AM, Tara Mclean <[EMAIL PROTECTED]>wrote: > > >> I will admit that I have questioned my self as to whether this is > >> needed since arPerson would do just fine. Do I need to know what the > >> array contains? And arPerson looks a bit neater. > > > What about dropping the "ar" too (is this Person a pirate?) and just call > > it "people." Plurals in variable names mean collections of variables, > > assuming there are some sanity-preserving conventions the writer is > > following. =) > > > In other words, I'm with Barney on that aspect. > > > Sammy Larbi > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
