SQL Server, Analytics, .Net, Machine Learning, R, Python
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning
Sunday, June 25, 2006
Long and Short Variable Naming
Darren Neimke has been talking about variable naming and how long variable names should be: Debunking popular myths. I agree that long variable naming can and has been abused but would also like to throw in the following points (this is a edited version of my comments):
I have seen the situation many times when a programmmer will construct a poor abbreviation just because a rigid coding standard enforced that variable names should be at most N characters, and using the more full and descriptive name would have gone over by a few chars (say five too many). So you end up with a 10 character cryptic (or ambiguous) name as opposed to an 18 character descriptive name. I'd definitely prefer to see and read the latter.
In my view, an even bigger give away of regions of code that warrant closer inspection is when there is a mixture of very terse and very verbose variable naming, either because it’s the work of more than one programmer or just one who was unsure of what they were doing.
I agree that really long names are bad for the reasons Darren mentioned, but also for the reason that they make code harder to read, and therefore slower to understand, and therefore harder to maintain.
I guess in the end it’s about common sense; I obviously try to keep variables as short as possible whilst maximising their meaning. My 32-character maximum length rule of thumb is slightly longer than Darren’s, although in practice it would be extremely rare that I would ever name anything that long.
MSN, Email: mitch døt wheat at gmail.com