... is choosing the right names.
Local variables need names. Instance variables need names. Methods need names, too, as do classes, columns, delegates, events, files, forms, parameters, projects, products, services, styles, tables, and of course – namespaces. Namespaces are nothing but a name! So many names, and so few words to use.
I was thinking about the amount of mental effort I expend in basic programming activities – like picking control structures (foreach versus do-while), or data structures (stacks versus lists), versus the amount of effort I expend to name all the abstractions in the simplest piece of software. Loops and structures are easy – naming requires a great deal of time and thought.
After all these years of thinking about names, I still struggle to pick the perfect name. Naming is a skill I need to improve - because names are important. I can use all the right patterns, have 100% test coverage, exceed every performance requirement, and still feel like I've failed if the names produce a piece of software that looks amorphous carbon:
Bad names kill good software by making the software un-maintainable.
Here are some interesting reads on naming:
I'd like to find more. Know of any others good ones?
Comments
Design Guidelines for Class Library Developers - http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx
1. Accroding to me i dont beleive in prefixes like strName or ClsEmployee or objAccount.
I have found that the more closer your identifier names will be to the real world application the more accessible they are.
I would use 'Employee' as class name
and depending on context e.g if i am creating a new employee i would create an object named newEmployee unlike objEmployee.
2. For control naming i prefer suffixes like instead of txtFirstName i write FirstNameText
since for me its easy to remember that a form has a first name field, rest intellisence will take care.
3. Your memory and intellisence can sync better with real names.
4. I hate when people prefix their database objects like tblEmployee or vwWeeklyReport.
i prefer real names or suffixes for help e.g. Employee is better table name
and WeeklyReportView is a better view name. even if you use tools like SQL prompt or SQL Server 2008.
Hope it helps.
http://mindprod.com/jgloss/unmainnaming.html
Just kidding, but very fun to read anyway
I've been thinking about this "names" thing. It's the bane of my existence too. I agonise over what to call things.
I just wanted to swing by and tell you that the other day I had a meeting with a customer, and they explained to me that they deleted all the data from Sheet1, then imported data from Blah, then run Query1, then Query17, then Query6667 ("Oh, let me tell you, on that day I just felt like including the number of the beast"), and then deleted the data from Sheet2, and then...
Seriously... that's what happened. Had to have the process explained to me, and this guy had never taken names seriously in his life. The thing that sucked was... I knew exactly what the process was. Didn't make *any* difference to me at all that Sheet1 as TheDataBeforeAggregation and that Sheet2 was TheDataAfterAggreationWithBlah or that Query1 was GetAllTheDataFromWhereeverAndPutItInThePreAggreationTable and that Query17 was AggreateAllTheDataInThePreAggreationTableAndBlah and that...
I told you I'm drunk, huh?
Anyway... I'm starting to lean toward x, y, and z. Stop me if I'm wrong.
Change the name or it will disapear
Is in fact how to remove CODING from software development. Naming conventions is NOT in any way a challenge.
We already practically removed it from the user level, now time to remove it completely from application development level, next is software development and last is systems/OS development.
I always liked i, j, k myself.