Code should be written for developers to read and computers to execute.
This idea means that code should be written cleanly and legibly enough for one developer to communicate the implementations for any solutions they’re working on to the next dev, both now and months (or years) in the future.
There are more than a few ways for engineers to ensure quality code, and we gathered some top tips from two LA engineers.
Firstly, they said that consensus on best practices is crucial for clean code. Devs should agree on even the small stuff, like indentation and capitalization, and avoid making changes based on personal preferences. Naming conventions should also be standardized and specific.
In most instances, code simplicity is more effective than complexity, unless advanced code is necessary to solve a problem. Engineers should always leave code a little bit cleaner than they found it, making improvements where they can or flagging larger issues for the team to discuss. And when it comes to code reviews, the more the merrier, our respondents said.
Peer reviews ensure that agreed-upon best practices are being followed, and bugs are caught early in the process. Not to mention they’re also great mentoring opportunities and help future-proof code, making it accessible to engineers across time and experience levels.
“Most of the code that developers work on is not new code,” said CCC Senior Manager of Web Development Mike Wilson. “They’re mostly enhancing existing features, fixing bugs and maintaining working solutions.”
Wilson, who has worked at the AI-based automotive and insurance technology company for six years, said codebases should be kept as simple as possible, since they could be worked on for years by both junior and senior devs.
When it comes to writing clean code, what are some best practices you follow?
Pick one style and stick to it. We use Microsoft Visual Studio and its configurable formatting rules. Some team members use JetBrains ReSharper. EditorConfig is another easy tool that has specific rules teams should follow, such as tabs versus spaces. We also use SonarQube for static code analysis to help with stylistic standardization and code quality checks.
Another approach we use is code linting. A linter might be used to find a switch-case statement without a break, where a compiler would consider it to be valid code. We created custom lint rules to prevent code from being used across module barriers and accidentally checking in unit-test control code.
Only write advanced code when necessary to solve a problem.”
What are some bad coding habits that you wish every developer would stop doing?
Documenting code is highly encouraged. However, it can easily be overdone. Rather than explaining what a block of code is doing, maybe the approach needs to be improved. Assess whether functions or variables need better names. Code comments should explain why something is done a certain way rather than what the code is doing. Even that practice should be done on a limited basis since it’s easy for code comments to grow outdated over time.
Debugging code is twice as hard as writing code. Therefore, cleverly written code can be impossible to debug. Clean code should be as simple as it needs to be in order to get the job done. Only write advanced code when necessary to solve a problem. Writing code is about clarity and readability. Compilers generally condense and optimize statements. So little is gained in having long methods or lines of code. A codebase doesn’t have to be difficult to read irrespective of the complexity of the business domain.
How does your team make clean code a priority?
We ask ourselves a few questions when writing and reviewing code: Am I going to be able to quickly understand this code in a year? Can a junior team member understand this? Does the code match the team’s — or a specific individual’s — style?
All committed code goes through a review process. During reviews, we ask questions instead of making declarations and point out positives, not just the negatives. We make heavy use of continuous integration, where code is run through a series of pipelines to ensure validity. Part of that pipeline is automatically executing the code linting tool.
Jesus Quezada, a software engineer at mobile gaming company, MobilityWare, said his team ensures quality code through established guidelines as well as frequent code reviews.
Shared responsibility, Quezada said, means every team member feels they can speak up about best practices.
When it comes to writing clean code, what are some best practices you follow?
The most important habit in writing clean code is to keep it simple. For example, when creating methods, I ensure I have a clear understanding of what this method will do. Then, I do it well. I put extra thought into making sure everything is appropriately named to tell a clear story of what something does. When I’m done, I do a final pass to add comments to areas that may be difficult to understand at first glance. My goal is to make sure that when someone reads the code, it’ll be easier to understand, even if that someone is a future me.
I put extra thought into making sure everything is appropriately named.”
What are some bad coding habits that you wish every developer would stop doing?
Prematurely declaring a method as virtual, and defining methods as public when they should be private. In standalone projects, these habits aren’t bad. They become issues in shared libraries. Methods in shared libraries propagate out to multiple projects. Then it becomes hard to know if little tweaks are going to cause breaks in another project.
Instead, methods should only be made virtual with an immediate need to override the method. If everyone shares this philosophy, then I can assume that virtual methods I encounter are already overridden. That way, I know I need to be extra cautious with my changes. Similarly, I try to limit the scope of methods to private until there’s a compelling reason to give out more access. This idea prevents unnecessary dependence on the method from too many sources.
How does your team make clean code a priority?
Two words express our team philosophy: agile reliability. Our code should solve the problems in front of us while also being dependable. We have a few ways of ensuring every line of code is well-thought-out and thoroughly vetted.
First, we set agreed-upon code guidelines. Second, every commit is peer-reviewed, with no exceptions. Code reviews help ensure that changes have no hidden defects, follow our principles and solve the problem they are intending to solve. Because everyone does this, each team member feels empowered to speak up about both the code and the processes that keep it clean. We then use that information to improve our procedures for the future.
