We’ve all been there before, in that wonderful position of taking over someone else’s code. During my time as a consultant, I have been in that position plenty of times. There were the projects where days were spent laboring to understand how some code is even working. On other projects, the code quickly revealed nice functionality with no headaches or yelling and the project was quickly completed. The difference? Code cleanliness.
Take a look:
We have all met this person before. You may even be this person. Writing clean code is important and will help save headaches later, not to mention the computers that will be spared the verbal abuse. Whether you think you write clean code or you know you need help, here are seven tips to improve your code cleanliness.
1. Use Naming Standards
Decide on a naming standard and stick to it. Maybe you will prepend “_int” in front of all integer variables, or add “btn” to the end of any button id. If your team or company already has standards, be sure to follow them.
2. Revise Your Logic
Pseudo-code, use flow diagrams, or discuss it with a coworker before starting. By refining your logic and complex functionality before you code you save the headache of refactoring later just to make your function cleaner..
3. Avoid Large Functions
Two rules: 1) Instead of repeating code break it out into a function. 2) Keep functions to only one job. You should have two different functions if you need to do two different things. Don’t try to cram logic into one function.
4. Use Proper Indentation
One of my biggest pet peeves is when code is not properly indented. Sure, the compiler doesn’t always need that and maybe you know what is going on, but it is very hard for someone else to look at code that is left aligned and quickly understand what it is doing. It becomes very difficult to see the beginning and end of functions, loops, and any other potential syntactical errors.
5. Use Explanatory Comments
This is one of the most underestimated and underused tools in most projects. Leaving good comments behind can really help your teammates or future developers understand what the code does.
6. Don’t Overuse Comments
Keep your comments clean, straightforward and to the point. Comments are not made for writing explanatory notes to self (/*I will finish this later*/), blaming others (/*Joe did this…*/), or erasing code. Keep your notes in your favorite text editor, and use comments for their proper use.
7. Delete Old or Unused Code
Don’t hide old code in a comment, get rid of it! No one needs to see that old method that has been refactored 5 times. Don’t let it sit around wasting space and confusing new teammates. Nothing is more aggravating than trying to understand and debug a particular piece of logic, only to find out that it's not even used. Don’t worry, if you ever need that function again, just grab it from source control.
Bonus Tip: Keep Logic in the Code
Logic is hard to understand in query languages and is best done in code. Maybe there was a time back in the day where it was best to write stored procedures to handle your logic. That time is over. Do not put logic in the database. If you want to keep your project clean, write your logic in code. Can you use stored procedures? Sure you can. You can use them to gather the data you need or format data to be saved in the database, but keep complicated logic in your code.
These are not groundbreaking ideas. Most of us are probably already familiar with them, but for some reason we don't apply them. One day when you are the guy taking over a project, wouldn’t it be great to find out that the code doesn’t look like a house built by a child with nothing but a hatchet? Don’t be lazy, be clean.
If you enjoyed this blog, would like to know more, or need someone to clean up your code, please don’t hesitate to contact us with your questions or comments. Here at Sparkhound, our developers follow these and many other great coding practices. We would love to have a conversation with you today about making your business the best it can be through leadership and technology.
Information and material in our blog posts are provided "as is" with no warranties either expressed or implied. Each post is an individual expression of our Sparkies. Should you identify any such content that is harmful, malicious, sensitive or unnecessary, please contact firstname.lastname@example.org