Clean code isn’t just a matter of personal preference. It’s also part of being a good teammate and collaborator.
“The codebase is part of the workplace, and everyone needs to work together to keep it clean and efficient,” said IMC Trading Software Developer and Team Lead Matt Gokel.
The eight-year veteran at the trading firm said — for the sake of themselves and their teammates — devs should devote time to keeping their code clean, just as they would the physical office they all share. And having a strong, collaborative culture underlies both of those ideas.
Alex Wolek, a senior software engineer, agrees. Wolek said the team culture at cloud-based healthtech platform Strata Decision Technology helps ensure clean code because developers are open to giving and receiving feedback that keeps code crisp.
In the pursuit of code cleanliness and building off of a culture of camaraderie, both Gokel and Wolek emphasize readability. These Chicago professionals recommend engineers code with the idea that their work will be as readable as a good book for the next engineer that examines it. Gokel and Wolek shared the simple best practices they've implemented to facilitate that legibility — and keep code clean and tidy in the process.
When it comes to writing clean code, what are some best practices you follow?
Clean code isn’t just a stylistic preference or about sweeping up occasional cobwebs. It is an important design principle, in line with performance, maintainability and testing. If it isn’t already, clean code should be promoted to a top-tier requirement.
Start simple, emphasize readability and stay practical. There’s always a deadline or a person breathing down your neck. Cutting corners and hastily scribbling in personal short-hand all but guarantees a bug, an operational issue or compromises a future colleague’s productivity. Temper this emphasis with practicality. Prioritize what’s important now, do it cleanly and get the job done.
Start by trusting the integrated development environment’s cues to simplify or improve what’s been written, and even auto-correct typos. When reviewing, ask whether the right problem is being solved. Look for opportunities to refactor and reuse existing, well-tested code. Emphasize descriptive method and variable names, ensuring that teammates will be able to read and understand what’s written. Remember that the codebase is part of the workplace, and everyone needs to work together to keep it clean and efficient.
Don’t turn a rule-of-thumb into an infallible doctrine.”
What are some bad coding habits that you wish every developer would stop doing?
It’s easy to conflate code that isn’t clean with bad code, but that simple language difference can cause unnecessary conflict. Offer constructive feedback. Explain how the code can be cleaned up rather than wrinkling your nose or showing frustration.
Don’t turn a rule of thumb into an infallible doctrine. Rules are valuable when the exceptions can be understood and justified. A common example is a mandate for junior developers to reduce duplication at all costs. Duplication carries a high cost. However, taking this idea to an extreme can make it hard for future developers to understand what needs to stay the same versus what happened to be the same during implementation.
Clean-up commits are commonly done as follow-up work. Look for opportunities to clean before committing your own changes. Take time to understand existing code, and find ways to refactor or repurpose it before adding new functionality. It will pay dividends in the long run.
How does your team make clean code a priority?
Writing clean code is a shared responsibility where colleagues accept feedback, acknowledge mistakes and hold each other accountable. Our keys to making clean code a reality are embedding this concept in our culture, prioritizing it in code reviews and setting expectations for development.
Sometimes cleaning code requires context from a more experienced developer. Ensure that code in review is readable. Fix simple mistakes before asking a teammate to look at it. These practices mean reviewers can provide meaningful feedback rather than enforcing style. We leverage automated builds to highlight the obvious issues, then encourage teammates to challenge our design decisions and ask questions.
When it comes to writing clean code, what are some best practices you follow?
When I think about clean code, I try to remember a quote by one of my favorite authors on software development, Martin Fowler: “Good programmers write code that humans can understand.”
I try to emphasize code readability. Another engineer should be able to read someone’s code and understand exactly what it’s doing. Since we have a sizable engineering team, I try to write code that is explicit so the next developer can easily see its intent. Code should almost read like a good book. Our team uses the Agile methodology, so I try to keep maintainability in mind as well. Clean code is flexible and can be easily refactored with evolving business requirements.
Code should almost read like a good book.”
What are some bad coding habits that you wish every developer would stop doing?
A bad habit I sometimes see is unclear naming conventions. Classes, methods and variables should be clearly marked. Devs should be able to tell exactly what a method does by reading its name. Sometimes there are vague, misleading names like “Process” or “DoWork” that actively mask intent. The next person to work on that code needs to read through the entire method to figure out what it does.
Also, I often see developers not adhering to the single-responsibility principle, one of the SOLID principles of object-oriented programming. A cleanly written class is focused on a single concern. It should do one thing, and one thing well. Many times, there will be a class filled with too many pieces of functionality. Another bad practice is cramming too much logic into one method. If a method has “And” or “If” in its name, that usually means it’s doing too much.
How does your team make clean code a priority?
First, all code must be peer-reviewed. Code reviews are done through pull requests of feature branches. Nothing can be merged into the master branch without approval. Pull requests must pass a series of build checks as well, including the passing of all unit tests. We also have a static code analysis tool integrated in the build pipeline. This tool can identify certain code smells and security vulnerabilities.
But I think the biggest way Strata promotes clean code is through the culture of the team. Our team members have open minds and are receptive to feedback, making it easier to collaborate.
