<p><pre><code> "There are only two hard problems in Computer Science:
cache invalidation and naming things."
-- Phil Karlton
</code></pre>
The article is absolutely touching a worthwhile subject but imho an important tip is missing: Don't be afraid of <i>re</i>naming things later. Modern editors make mass-renaming easy and it's almost impossible to get everything right from the start.
I learned about 7 years ago that "choosing the right name" for things was slowing me down. I was breaking flow every 2 minutes or so to come up with function names. It was like an unintentional form of procrastination.<p>It was a hard habit to break, but now I just write a first draft, and go fix the names afterwards if I have to.
Not to detract from the actual point of the article, which is extremely good, but this gem popped out at me:<p>"Creating a root namespace named after your corporation will haunt you. Companies and brands get renamed, acquired [...] Oracle's Vending Machine division was once Sun Microsystems"
CamelCase in the DataBase?
Insane in the brain!<p>Pushing type information and other metadata into names is bad software engineering. Names should be from the problem domain and not co-mingled with implementation concerns.<p>The database section is so wrong!<p>(1) "driverLicenses": it's a "driver's license", you don't want to put an apostrophe in the table name, so go with driversLicenses<p>(2) SQL's not real good with case-sensitivity, use underbars to separate words in SQL, so DRIVERS_LICENSES<p>(3) Since you're going to use the table name in your query anyway, there's no reason to repeat it in the column names; naming your tables and columns consistently makes maintenance and automation easier: ID not driverLicense_id
If you really, really want to push metadata in there, do it as a rename so you don't step on everyone else's toes: SELECT id as myReallyLongAndUnnecessaryTablePrefixedIdentity_id…<p>(4) Pluralization of tables stalls your mental cache especially in combination with the table-name-in-the-column-name idea: SELECT driver<i>License</i>_id from driver<i>Licenses</i>, SELECT <i>medium</i>_id from Media? Some nouns have multiple valid plurals (do I select from the Persons or People table to find a Person?), some nouns are already collective, etc.<p>(5) Prefix views with "v_": uh yeah, because its much easier to rewrite queries and mappings if a view is replaced with a table than it is to type, say in postgres, "\dv".<p>(6) "Use a postfix to show the kind of key": uh no, use the database's type system to show the kind of key through the use of types, domains and check constraints.<p>upshot: CREATE TABLE DRIVERS_LICENSE (id ...)<p>_skidmarks for private fields? uh, if that's what your language does, fine, otherwise how about using the language's built-in visibility keywords?<p>StudlyCaps for method names and class properties: better to stick to the language's style guides, teaching a junior programmer to write [myDocument SendToHNews: dvmby_timeStamp] or myDocument.SendToHNews(dvmby_timeStamp) is giving them some unlearnin' to do at their next job.<p>"Don't make them singular because you have an ancient ORM", this is a straw-man argument that applies equally to all his naming advice as well: if you have a good ORM you can call tables "quetzalcoatl" and remap to "MesoamericanDeity". Use appropriate names in the schema and object model and let the ORM sort-out the differences.<p>"Oracle's Vending Machine division was once Sun Microsystems"
<i>that's</i> funny!
"If your table is called "driverLicenses" and needs an ID column for its primary key, then call it "driverLicense_id" instead of just "id". This will make the origin of the column clearer in result sets"<p>I really would rather type in "id" when I writing a SQL query against my data, than, "driverLicense_id".
Hungarian Notation? Gaah! If I ever have to read a mluspidBlah = ConvertToSomething( mlusptBleah ) again I'll barf. That's the kind of stuff that keeps me up at night.
I very much agree with the authors <i>promotes insight</i> assertion. Accurately naming at least functions and classes increases the value of your conceptualization of a problem. I have even taken to writing a non-programming description of my problem first, perfecting that, and then programming it.
The only useful naming convention was described by Bjarne Stroustrup in his C++ book: "capitalize type names, don't capitalize anything else".<p>If you want to prefix your private members with "_", you are using the wrong IDE (or the wrong language, like here: <a href="http://news.ycombinator.com/item?id=826119" rel="nofollow">http://news.ycombinator.com/item?id=826119</a>). If you want to prefix sanitized variable names with "s", you should find a better way of sanitizing them and read less of Joel. If you want to name hard-working method like "DistinctRequests", remember that you are "hiding behind your names" and contradicting yourself at once.
"The correct naming of things [...] makes you attractive to women."<p>I'm curious about this kind of writing in a programming related article. Did any women who read this article feel discomfort when they read this sentence?<p>I am guessing no, but I would like for the women of this community to answer.
The only naming guide you'll ever need:<p><a href="http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html" rel="nofollow">http://developer.apple.com/mac/library/documentation/Cocoa/C...</a><p>:P
Funny this ends up here. I was asking earlier on twitter today about whether there was a C# convention for naming private variables.<p>Seems that it is indeed _variablename , while I don't know if I like it, it would seem that it is more common then I thought and specifically mentioned in this article.
I disagree with "Avoid discussing hard work" Things should have names indicative of what they do.<p>Giving a costly operation an attribute sounding name is going to give some poor future developer an unpleasant surprise.
"you shouldn't even be using that because it means you're in a for loop when you should be using foreach."<p>I am not sure whence arises this nugget of alleged wisdom...