Ben Forta

AdobeStock_455007340

Naming Conventions? Give Me A Break!

The lists have been buzzing the past few days over the use of XML, framework configuration storage, and more. And the conversation has more recently shifted to a ferocious debate about naming conventions. And to be brutally honest, I am both dismayed and appalled.
As far as I am concerned there are no absolutes when it comes to naming conventions. I personally insist on two things:

  • Consistency (whatever you do, do all the time)
  • Descriptiveness (“foo” is unacceptable, as is “x” and “i1”, although I may allow the latter as the index variable within a loop, perhaps, and perhaps not).

That aside, have a party. If you want all caps, go for it. Camel case? Sure (although, I can just see it now, a debate over should it be ArrayAppend() or arrayAppend() or …). All lower case? Fine. Starting with $ or _ or any other character, that’s fine too. The objective is that you, and whomever has to work on your code next, can easily ascertain what the code is doing and why – that is it. Variable naming choices say absolutely nothing about the quality of the code, the caliber of the developer, and whether or not the application is architected soundly and built properly.
Or put differently, if your app design is so perfect that all you have left to worry about is whether or not to name your variable firstName or FirstName or first_name or $FirstName – well, it’s probably time to find something else to be working on.
Enough said.

11 responses to “Naming Conventions? Give Me A Break!”

  1. Barney Avatar
    Barney

    I agree wholeheartedly with everything you said, but there are some other factors to consider.
    Take a look at Rails, for example. It uses some [fairly strict] naming conventions to make it all work in a very transparent manner. You can change the conventions it uses to suit your tastes, but it’s a lot easier to just go with the Rails-provided conventions.
    Any place where code is made public, shared conventions are important, particularly if they’re not just stylistic, but also functional. A subtle point, for sure, but one worth mentioning in the hulabaloo.

    Reply
  2. Jeff Dopp Avatar
    Jeff Dopp

    I totally agree with that. I sometimes wonder how some people get any work done with all of the time they spend debating sometimes meaningless topics.

    Reply
  3. Ben Forta Avatar
    Ben Forta

    Barney, a very valid point indeed. Although I think that that might fall under my ‘consistency’ point.

    Reply
  4. rafael Avatar
    rafael

    totalmente de acuerdo.
    ser coherente y claro es lo esencial.
    just translate spanishToEnglish or Spanish2English? 🙂

    Reply
  5. Barney Avatar
    Barney

    My point was more that those conventions in Rails had to come from somewhere, and that somewhere was undoubtedly a heated debate on the rails-dev mailing list. Any sort of tool that relies on naming conventions has a valid reason to have seeming stupid discussions about them.

    Reply
  6. Eduardo Slaccuchi Avatar
    Eduardo Slaccuchi

    This is all true, to an extent. If the language allows it, then it is "legal." If you want to name your variables (consistently, you warn!) things like $!___00390282!, the system will let you.
    This neglects, however, important aspects of style and convention. If you spend some time looking at the Java API, you’ll find there are very rigid constraints in place regarding capitalization of objects and methods. Most C/C++ code you encounter will employ similar practices.
    Yes, it’s legal to name your variables whatever you want, but in a larger, collaborative body comprised of mature programmers, certain standards are expected to emerge, which actually improve the aspects you mention above (readability and consistency). Even stripped of its context, you can look at a line of C like:
    if ( amount > AVAILABLE_CASH ) …
    and know something about the nature of "AVAILABLE_CASH." This is only possible when a generally accepted style has emerged and is followed. It’s a mark of maturity to have naming conventions, despite the fact that some may feel constricted.
    Carry on!

    Reply
  7. Mujeebur Rahmansaher Avatar
    Mujeebur Rahmansaher

    Naming conventions should be always kept in mind but up to an extent.As long as the app works , who care about the var names …:) !

    Reply
  8. Damien Avatar
    Damien

    I tend to use X as a counter within loops that have very few internal commands, but anything longer than two or three lines gets a "real" counter name. Aside from that, I concur.

    Reply
  9. Oliver Merk Avatar
    Oliver Merk

    Ben,
    When I teach CF, I, too, maintain the "be consistent, whatever you do", philosophy. However, when I look at someone’s CF code, I tend to think they’re a more seasoned developer when I see them following the standard Java naming conventions. A prejudice, maybe, but one which a potential employer may hold as well.
    Cheers,
    Oliver

    Reply
  10. Steve Powell Avatar
    Steve Powell

    We have this all the time with all our databases. We have Oracle DB’s, SQL DB’s and MS Access DB’s. So getting consistent table names, views, columns and such is just a complete nightmare.
    Lots of sgreed standards that only one or two of us stick to.
    Not so bad moving stuff between Oracle and SQL but trying to bring some of the MS Access stuff on board is just a nightmare.
    Sensible things like NO for NUMERIC numbers and NUMBER for numbers stored as strings. Always call the ID column TABLENAME_ID. Tables called _TBL and views called _VW. Never use plurals USER_TBL not USERS_TBL etc.. All makes life easier when you’re building it. You don’t have to constantly look up column names.
    So I disagree with anyone who thinks it doesn’t matter. I always think the guys that assemble some of the spaghetti I inherit must be much smarter than me because I can’t keep all those names and slight variations (USER CODE, USER_CODE, USERCODE, USER_CD) in my head. I just use a really simple system and stick to it.
    And thats way before we get to naming variables. Don’t even get me started on tables that don’t have indexes or PKEYs on them…

    Reply
  11. Bill Avatar
    Bill

    While I agree that naming conventions aren’t that important having an agreed upon set of convetions doesn’t hurt anything – in fact I think it helps.
    If a team all uses the same naming convention for things then reading/code-review is much easier and I think maintenance is as well because I am immediately comfortable in the other person’s code.
    If I switch jobs and that new place has a different convention – no biggie, just so long as their is consistency across the developers and not just one method for bob and another for joe and a third still for sally.

    Reply

Leave a Reply