I recently wrote that developers have to strike a perfect balance of delivering high-quality software that works well, looks good, and is delivered on time.
Of course, it's impossible to "have it all" unless all of your clients are fabulously wealthy and have all the time in the world.
I wanted to delve more into the aspect of Syntactic Elegance.
Just because nobody will ever see the code, doesn't mean it can be sloppy!
Code That Speaks For Itself
What I mean by Syntactic Elegance is code that appears to be simple and easy to follow, but that actually does a lot. Think of a high-end luxury sports car. With smooth curves and perfectly glossed paint, it seems both simple and supple at the same time. It got that way because someone spent a lot of time carefully refining and polishing it.
Unfortunately, in most cases, clients can't afford to wait for you to test and refine every aspect of your code. But just a few habits go a long way to producing elegant code.
Here are my top three recommendations
Avoid acronyms! Especially obvious ones.
Consider a scenario where you have a model used solely for serializing a class sent back and forth between the server and client. Some might call that a POCO object, or a DTO model. Don't! Not because there's debate about the meaning of both DTO and POCO (or as my coworker yells each time "you don't need to say 'object' after 'DTO' or 'POCO' because the word 'object' is part of the acronym!'), but because it should be clearly obvious what something is simply by looking at it. All modern IDEs show you what an element is simply by hovering the mouse over it or navigating to the definition. Embedding the type of something in the name is tantamount to calling your manager "JimBoss"! Name an object for what it truly is! Instead of CustomerDto, simply call it Customer.
Spell things out!
I once had a coworker who consistently used unnecessarily short and arbitrary abbreviations in their code. I had to hold myself together one day when they called me over to help work out some logic and I noticed they had used x, y, and z as variable names in code they had actually committed to the repository! To me, it seemed 2 parts lazy and 3 parts naive. Don't get me wrong, I tend to begin by inventing new code elements with whimsical variable names like pizza and cat until I understand their purpose and functionality. But as soon as you get to a point that you reasonably know what something is, give it a name!!! Humans have such a deep desire to name things that we arbitrarily name the full moon at perigee differently than the full moon in January differently than a second full moon during the same calendar month!
A good name conveys what the code does, what the object represents, and what the consequences of using it might be.
On one project, one developer wrote a method named GetNextValue that returned the next logical value in an alpha-numeric sequence for a kind of record identifier. Seems innocent enough. But, under the hood, in order to get that "next" value, it inserted a row into a table that stored the value it came up with (to ensure it was unique,) and also updated the Consumer table with that unique value. In other words, the method was anything but a simple Get! It altered the database under the hood! A good name should reflect that, perhaps with a name like RegisterConsumerRecord in this case. This is particularly crucial if other developers intend to reuse the method or if it might have unintended consequences (as was the case here). The day another developer innocently re-used that method had disastrous consequences because the poor naming of the methods they developed led both developers to misunderstood what the other's code did.
Observe the accent and style preferences of the language of the code
Which is more correct: to place the opening curly brace in-line with a method definition, OR immediately below it on the next line?
if(myValue > 42)
{
DoStuff();
}
Figure A
OR
if(myValue > 42) {
DoStuff();
}
Figure B
The correct answer is: It depends on the programming language in which the code is written! Javascript developers prefer the style in Figure B, whereas C# developers prefer the style in Figure A. Both developers, who are both equally amazing, will say the other clearly just looks wrong! Should you use camelCase or kebab-case for variable names or other elements? The correct answer is: It depends on the language. Every language comes with it's own "accent", and any time you need to switch contexts to another language, do everyone a favor and adapt your code style to the preferences of the language your code is in!
You can't have it all, but cultivating a few simple habits can make your code more approachable for the next developer who follows in your footsteps!
Happy coding!
Top comments (0)