Five Months Without Hungarian Notation And I'm Loving It
Posted November 19, 2009 at 6:58 PM
About five months ago, I expressed a growing concern that my coding methodology at the time was forcing me to create contradictions within my naming conventions. As such, I decided to completely dump my pseudo Hungarian notation for a while and adopt a more traditional, headless-camel-case approach to see how it felt. That was back in June; now, in November, I have to admit that I am really liking it. Consistency is just so freakin' sexy, and adopting headless-camel-case across the board has made things extremely consistent.
| | | | | |
| |  | | ||
| | | |
Post Comment | Ask Ben | Print Page
Newer Post
jQuery UI 1.7 By Dan Wellman
Older Post
What Request Data Does ColdFusion Builder Post To Extension Handlers?
Reader Comments
I abhor camel casing as much as Hungarian notation, at least insofar as it was used by Microsoft.
Look at some old WINAPI code and you'll see lovely variable names like this:
lpsz_name
lpsz means long pointer to a zero-terminated string.
When I was doing C++ programming, I adopted something one of the authors I liked recommended: Use underscores. I know that is verboten in the CF/Java world.
loop_index is so much nicer to me than loopIndex or LoopIndex.
Another annoyance was when coders would shorten variable names by basically removing the vowels. Ugh.
Ben, I prefer the name 'nerdCaps', but if you're calling it headless camel case I fixed your picture...
http://www.dustypixels.com/downloads/headless_camel_case_its_a_beautiful_thing.jpg
...maybe I've been playing too much Left4Dead2? :)
I had to click the link. I just had to....
Atta boy. I've been a HUGE fan of headlessCamelCase since I discovered it right at the beginning of my career. It's just so readable and fluid to type. Pretty much the only time I don't use it ( and use underscores instead ) is in certain types of dynamic and generated code where a physical delimiter simplifies parsing and stitching.
nerdCaps FTW fuhSho.
iLoveHeadlessCamelCase = true;
i_dont_like_using_underscores = true;
I_USE_UNDERSCORES_FOR_CONSTANTS = true;
/* Hmmm, still first one looks better. I couldn't read 500 lines full of the 2nd one. But I do use underscores in the html view templates because the underscores makes it much easier to spot in a bowl of spaghetti :) */
@Adam +1000 for your pic! LOL
Love the pic @Adam.
Personally, I prefer headless Camel Case. For the most part I stopped identifying my variables with prefixes (ie. str int boo) when I started with CF.
@Steve,
Yeah, shortening variable names is insane! I have seen developers shorten a variable by removing ONE vowel. Really? Really? Is that necessary?
@Adam,
Ha ha ha ha, classic! Great PS job. Did you use the healing brush?
@Brian,
I used to be a huge fan of prefixing with data types (ie. strName, intCount). But, after a few months of rocking out "name" and "count", it's been really good times.
The only problem I have is when I have variable names that are different only by data type. For example, when I convert a response string to binary for use with CFContent, I start to have to pick names like:
- response
- binaryResponse
... but in cases like that, I suppose it's one of the few times that the data type IS actually relevant.
> Did you use the healing brush?
Actually, I think that was the torture and disfigure brush. It's hidden in one of the sub-menus.
If Dave Watts were here he'd link to this article and remind us that true Hungarian notation isn't actually just prefixing variable names with their type.
http://www.joelonsoftware.com/articles/Wrong.html
My mentor started me on headlessCamelCase and I've never felt the need to deviate. It Just Works.™
@Brad,
Yeah, I remember learning that; although, I remember the actual explanation of Hungarian notation being a bit too conceptual for me. Either way, been liking what I am doing now.
@Andrew,
I hear you.
I use the following and love it:
my.namespace.MyComponents.functionMethodsOrUDF()
CONSTANT_VALUES_OR_PROPERTIES
One thing I always try is to CamelCaseBuiltInColdFusionFunctions() so others can tell the difference and don't spend time looking through inherited components just because they forgot a built in function existed.
Where I work we have a rule, no abbreviations for anything and names that have meaning; it is funny how quickly you can get used to functions and variables that GoOnForeverButClearlyIdentifyWhatTheyAreFor. Makes code like a book that almost eliminates the need for comments. At fisrt I hated it but mostly because the rule was laid down by the .NET team, but after a while I got used to it.
@Marcel,
Yeah, I always err on the side of longer but more readable variable names. As for the camel casing of CF methods and the headless camel casing of custom items, I get around this by always scoping my custom methods (ex. this.doSomething()).
I've used headless camel case for years for not only ColdFusion variables, but also SQL tables and fields... pretty much everything involving code. I also subscribe to the "don't abbreviate and clearly describe your variables with their names" mentality.
I've always hated Hungarian notation -- what a mess. Variables should be named pretty well so that they already hint to the data type, without having to put goofy abbreviations in front of the variable name. For example, my boolean / bit variables are always named something such as "isActive", "isPublished", etc, where reading them essentially asks a question and makes it instantly obvious that they are true/false boolean variables.
@Budd,
I also enjoy putting "is" or "has" before boolean-style values. It just feels good.
+1 for headless camel case ... been using it for years. Worked for awhile with the underscore in file names, but it's just not easy to type. Working on a code for several hours a day means always moving the hands up to get the _, and I'd rather not ...
Just like you, Ben, I strongly dislike the tblTableName ... I *know* it's a table already, thanks. And same for Boolean vars: 'active' could be a column holding activity types or something, but isActive always feels 'right' to hold the Boolean.
Ah, the joys of personal preference ;)
I used CamelCase and headlessCamelCase back when I worked on SQL Server - the former for table names, the latter for column names. So I used it in ColdFusion as well just for consistency's sake. But now that I work primarily on Oracle, I find the underscore indispensable (Oracle table- and column names are generally stored as all caps so underscores are necessary), and my variable names are mostly all_lowercase_with_underscores.
I can't stand Hungarian notation at all.
@Dcs,
Can you expand on why you use "_" in Oracle?
I ask mostly because SQL is the one place where I feel most emotionally tied to using "_". I cannot explain it more than well, it's the way I learned to do it (not that that has anything to do with right vs. wrong).
I know when I fully adopt headless Camel Case across the board, table names / column names are going to be the one place where it feels the most awkward.
Luckily, with ColdFusion 9's ORM integration, table column names == object properties, which will force me to use standard naming (and not emotionally fall back on "_" usage).
We use "_" in Oracle since all object names (including table names and column names) are all-uppercase by default (unless you wrap double-quotes around them). For example, if I do:
create table FooBar (etc.)
in Oracle, then a table named "FOOBAR" is created. Now, in some cases this might be OK. But when you have table names made up of 3-4 words then the underscores really help. Compare LOREMIPSUMDOLORSIT to LOREM_IPSUM_DOLOR_SIT - one of those is definitely easier to read.
Now, you could create lowercase or CamelCase tables in Oracle if you use quotes:
create table "FooBar" (etc.)
Here a table named "FooBar" is created. The problem with this is that you must always use quotes when referencing the table:
SELECT * FROM "FooBar"
and that can get a bit tiresome IMHO.
SQL Server doesn't have this issue, but I tend to use underscores there as well to ensure portability.
@Dcs,
Really??? That's is kind of crazy! I am, of course, referring to Oracle's man-handling of names. I wonder what the philosophy behind that is.
In that context, however, using underscores makes a lot of sense.
@Ben Nadel,
There's also the fun that Oracle puts a limit on the length of table and column (and other object) names: 30 characters. Now, I'm not a big fan of giant names to any object, but I do prefer descritpive titles over arcane abbreviations. Especially in mapping tables, you can't always pull off TABLE_A_TO_TABLE_B, if the table names are long, and the same with index names, like FK_TABLE_A_TABLE_B. Not an issue unless you're on Oracle, but can make design for multi-RDBMS platforms a real pain.
@Ben,
Yes, it is a bit crazy. And, of course, if you want to find anything out about a table in Oracle by querying Oracle's system views, you have to put the table name in all-uppercase (since comparisons in SQL queries are case-sensitive)!
@Jason,
The 30-character limit is really absurd in this day and age. Historically I've used the dollar sign ($) for mapping tables to shorten their names, e.g. TABLE_A$TABLE_B. This works on SQL Server as well as Oracle.
@Dcs, @Jason,
Is Oracle still a main stream database system? I don't ask that as a joke - I've never used it. I've really only ever heard of MS SQL and MySQL. Maybe one or two others. I've heard or Oracle, of course, but I rarely talk to people who use it.
Does it have a selling point for a particular set of use cases?
@Ben Nadel,
Yes, yes, yes, very widely used! Large enterprises that spent $2-$3 million on Oracle years ago and continue to pay Oracle DBAs to babysit the thing will allow only Oracle to be used going forward ... they have to make that investment look like it's worth it. Gets more difficult when Enterprise SQL Server can be installed for well under $100k ...
@Jason,
Ha ha, gotcha.
Well, Oracle does have some features that SQL Server lacks. For example, although SQL Server seems to have gotten around the silly 8060-byte limit for table rows, pages are still always 8K and extents are 8 pages or 64K, while in Oracle you can specify larger extents to ensure contiguous storage for large objects, meaning fewer chained rows.
I think SQL Server and MySQL tend to have more prominence in the CF world since a hosted solution will probably use one or the other.
@Dcs,
Good point re: hosting. I wonder if there are any shared hosting solutions that offer Oracle?
But even in the corporate world, the cost of bringing up a Windows Server box with a $5,000 SQL Server license makes it very attractive. I have also found over the years that SQL Server does a great job of handling all the thread requests that a web application throws at it, while I have yet to meet an Oracle DBA that understood what needed to happen to get Oracle to handle the open/close of many requests per second. I know Oracle syntax and a lot of tricks to help it out, like doing massive queries and then managing all the data processing in my middleware, but the tuning stuff was always a nightmare.
@Jason,
Everything you write is perfectly true, and SQL Server has some nice tools built into it that make administering it a pretty easy task (in most cases). However Oracle does have its advantages even apart from the tired old excuse of making an investment look like it's worth it. I will say that from a developer's point of view SQL Server has made some great strides; the difference between 6.5 and SQL Server 2008 is staggering, while the same can't really be said for the difference between Oracle 7.3 and 11g. Again, this is from a developer's point of view; a DBA might have different ideas (especially since one can more-or-less run SQL Server without a DBA; the same can't be said of Oracle).
@Ben,
I believe there are some shared hosting solutions available for Oracle, but not nearly so many as for SQL Server and MySQL. One solution that is readily available is Oracle XE (eXpress Edition) - if you have a hosted Windows or Linux VPS you could download it for free and install it there.
@dcs,
@dcs,
Absolutely true on the tools. I was lucky enough to get introduced to SQL at version 7 and by the time we were ready for implementation, we were on 2000, with a very nice toolset. I know I definitely dodged a bullet on 6.5 and earlier. All I know on Oracle, is that several clients each running 1 website apiece on CF could rarely get those sites to stop pegging the DB server, while we had SQL boxes running upwards of 50-60 databases for as many or more applications without a hiccup. I know that's not Oracle's fault per se, but it does speak to something about the architectures and their preferences for web connections, or so I've been told by several Oracle DBAs who thought I was nuts to suggest that a web application makes several requests to the database per minute.
Nothing against it, not a MS fanboy, but it just always gave us headaches that Oracle just didn't.
All of which is OT, of course ... sorry, Ben!
That should be "that SQL Server just didn't" ... end of a long day ...
