This might be obvious to some, but I've literally only realized a few months ago that when I write text, I will consult a thesaurus, whereas for some reason I've neglected to do the same when I code. I would spend hours agonizing on how to call a module, wondering if I won't need the same word later for something else, or if it might be making things a bit ambiguous for the next guy.<p>So I've started also using a thesaurus when I code and so far I'm happy with the results. It's been helpful in accurately framing some of the hazier concepts with interesting names. I also revisit the naming much less than I use to, because I'm comforted with the notion that if I couldn't find a better word with a thesaurus, then maybe there isn't an obvious one. I also now use words that are clear, but that I so far neglected to include in my programming vocabulary, because other more prevalent ones would jump in my mind and put a shadow on my naming creativity.<p>So, if you need some help naming modules, functions, variables and db entities, a thesaurus could help. Though, take care to not abuse of it.
Naming things to be clear in the beginning, stay clear as the system grows, is quite easily one of the hardest things in developing software.<p>Over generalized or specific names cause far more confusion and productivity loss than we think.<p>So take the time to learn what you're working on and how it works at the micro and macro level not only in the context of the application itself, but where and how the application fits in it's ecosystem.<p>Learn the lingo that your software's ecosystem uses, instead of inventing, by accident or purpose, your own clever and tricky rationalizations ending up in even more confusing concepts and names describing the same things.<p>The purpose of naming is similar to the purpose of software; creating clarity and empowerment, instead of more confusion and conceptual gymnastics.
For more rigorous naming, Eric Evans (in his excellent book <i>Domain-Driven Design: Tackling Complexity in the Heart of Software</i>) recommends documenting (and maintaining) your product's "Ubiquitous Language".<p>When developers (and the code), product managers, domain experts, and end users all use different terminology, then cross-discipline communication difficult and imprecise. A documented Ubiquitous Language enforces shared terminology (and meaning) for all communication within the team and in the code.<p><a href="http://domaindrivendesign.org/node/132" rel="nofollow">http://domaindrivendesign.org/node/132</a>
I am glad someone wrote this article - Now I know I can point it to my colleagues who are often baffled at the amount of time I spend thinking about names :)<p>I have found that when I can't find a good name for a method or a class, it's because I haven't really thought the reason for the same through. This is especially true for classes where I often realize that I am making the class do too much, or too little.<p>This book, "Clean Code" by Robert Martin has it's second chapter dedicated to naming things. A whole chapter! The book, alone for that chapter is worth the money. If you haven't read it, I highly recommend it.<p><a href="http://www.amazon.com/Clean-Code-Handbook-Craftsmanship-ebook/dp/B001GSTOAM" rel="nofollow">http://www.amazon.com/Clean-Code-Handbook-Craftsmanship-eboo...</a>
The first quote in the article; I thought it went like this:<p><i>There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.</i>
I find that thinking about good names for things can help guide you to design better code.<p>As Lars mentioned—if something is hard to name, it's probably because the thing you're naming isn't very clearly defined, is a bad/mixed metaphor, or is just plain hard to understand.<p>And if all else fails, there's always <a href="http://www.classnamer.com/" rel="nofollow">http://www.classnamer.com/</a> ;-)
My colleagues (developers) laugh when I pause few seconds to think about a proper name for a Java method. But I take it seriously, finding a class or method with proper name is way easier than an ambiguous name> Even a proper name with misspelling is considered bad in my dictionary.<p>Once in an interview, I asked the guy to write some code, he used variable names like "int ttttt=1;". I never saw him again!!
I think this problem comes up from the somewhat obsolete linear text nature of code. Instead of particular perfect names, we could be using tags. AbstractSingletonFactory is three tags. In some contexts I'd like to know it's a factory, in others I don't.<p>The bigger problem is we haven't moved on from the simple text representation of code. And this overly simple tool, text, is influencing the way we're thinking here. The Humble Programmer phenomenon in action.
I agree, naming is important and often overlooked, check out this quote by Josh Bloch:
<a href="http://www.elegantcoding.com/2011/07/software-frameworks-resistance-isnt.html#Names" rel="nofollow">http://www.elegantcoding.com/2011/07/software-frameworks-res...</a>
What I like to do is add a variables.txt file to the root of the project as a sort of legend for any unconventional variables I have to name. I try to stay as relevant as possible, but sometimes 'anospic' is better than 'average_numbers_picked'.<p>Good or bad, it works.
cool, and here i thought i was alone in needing to take time to name things correctly.<p>had to name a variable earlier this week and even broke out the thesaurus. best i could muster was years_experienced_absolute :/
Choosing the right metaphor in terms of OOP is equally important as well as the understanding the word's meaning and the implication of alternative meanings.