May 11
Beauty in Code
I have an obsession with all things beautiful.
Beautiful dresses, beautiful perfumes, beautiful flowers, beautiful jewelry, beautiful art.
And most especially, beautiful code.
Code that is clear and concise, as delicate as it is strong, and makes you want to read it.
The artist is never a master overnight, and cultivating your style takes time.
Here are four ways I measure my code’s aesthetics.
What’s In A Name?
The words you choose to describe your subject are incredibly important. We all know that as engineers, no code belongs to just us alone. Code is shared by all, analyzed by many, and used again by most. If your subject is cats, but your variable is “var1”, chances are more than good that your code is going to get confusing. If the purpose of your function is to populate a menu, or to handle the sum of orders, it’s going to be really hard for someone else to understand why you chose “function1”. It’s a great rule of practice to name your function with the verb it is accomplishing + the noun it is referencing. For example, “handleFormSubmitClick” is clear, while “handleEvent” might leave the next developer wondering which button you were talking about. Your variables, functions, and methods are telling a story; they should be descriptive enough to carry the reader to the destination.
The Simple Life
CoCo Chanel said “Simplicity is the keynote of all true elegance” and she might have been referencing the perfectly structured lines of her LBD, but had she been a software engineer, I think she’d agree that this applies to code too. When you are faced with a puzzle, the best strategy is to break it into more manageable pieces. You don’t jump into the middle and try to start solving everything at once; you look for your corners and straight edges, you group colors, you build in sections. In this way, it’s so easy for your cousin to join you and take over the lower left corner, building off of the structure you laid, or shuffling pieces to different sections. The general rule is one task per function, or the Single Responsibility Principle. The main argument against SRP, tends to be that the code becomes harder to navigate (so many files!), but code editors have built in tools to assist navigation. For example, in VS Code, hold Command + click on the name of your function or variable, and you will be transported to those sections of code (it’s magic!). When functions have more than one responsibility, they become more difficult to manage, to debug, to update. By keeping one task to your code, you streamline the process of maintenance, as well as save yourself time when troubleshooting is necessary.
The Philosopher’s Code
Consistency consistency consistency. Your indentations, your parentheses, your spacing, they all matter. Sporadic code, or code that changes vernacular from one line to the next looks sloppy and feels choppy. Mixing up your use of single and double quotes, misaligning brackets, and alternating how you space your code, makes it more error prone and easy to overlook what you’re looking for. Code editors, like VS Code (can you tell I have a favorite?), utilize multiple tools to makes this process even easier for you. For example, holding Shift + Option + F will automatically align your indentation. Having a code philosophy that you adhere to (along with sound formatting principles) will make your code consistent and readable. Again, you do not want your colleagues trying to guess at where you’re taking them. You want them to hop in the boat, feel comfy for the journey, and be able to spot the navigational stars.
One Code, Extra DRY
Once upon a time there were programmers all over the land writing the same code over and over and over again. It was during this time (the 90s) that two programmers came together to save the town, and their names were Andy Hunt and Dave Thomas. Our heroes wrote The Pragmatic Programmer, explaining that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. By following DRY code protocols, your code is more manageable and easier to update. This is especially crucial as your codebase grows. Look for patterns in your logic; by using loops (a task is executed until a specified endpoint is reached), functions (to separate logic), and frameworks (well maintained frameworks provide a lot of commonly used functionalities), you can keep your code viable and easy to read.
Code isn’t perfect and you won’t be able to follow these principles all the time (I know I can’t), but I do believe that this is a craft that can be cultivated, just like any other form of art.
“All change is hard at first, messy in the middle, and so gorgeous at the end.”
-Robin Sharma.
