How clean is your code? Are you sure?
Between deadlines, new product launches and routine maintenance, it’s easy to see how vetting new code can get pushed down a busy team’s to-do list. Yet blazing ahead without thoroughly testing code can lead to substantial issues — if not in the short-term, then in the future through technical debt.
So, how can teams make clean code a priority?
Unfortunately, said Mike Williams, a lead software engineer at Alteryx, there’s no one simple solution.
“In order to get clean, quality code, it takes a commitment from everyone on the team,” Williams said. “There are no magic bullets.”
Instead, tech teams have to build their own processes for writing, testing and reviewing code and decide what works best for them. To better understand how teams can find that perfect balance, Built In asked 21 software engineering experts from all over the US to give us their best tips and tricks when it comes to prioritizing clean code.
Top Tips For Prioritizing Clean Code
- Emphasize readability and start simple
- Use specific and meaningful naming systems
- Make sure to write comments and go into extra detail
- Leverage tools to help catch bugs, find security vulnerabilities and speed up the feedback process
- Pick one uniformed style of formatting and stick to it
- Take time to understand the scope of the problem and plan it out before jumping into coding
IMC Trading
Matt Gokel
SOFTWARE DEVELOPER AND TEAM LEAD
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.
Strata Decision Technology
Alex Wolek
SENIOR SOFTWARE ENGINEER
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.
theSkimm
Robin Bonatesta
SOFTWARE ENGINEER
Software Engineer Robin Bonatesta said consistent naming conventions, documenting code purpose, creating reusable modular code and writing thoughtful commit messages help her team at digital media company theSkimm develop clean code. From there, peer programming and code review should be performed diligently.
When it comes to writing clean code, what are some best practices you follow, and why?
Clean code is well organized and easy to read, which is especially important when working on a team. When programming, I try to evaluate if my code will be easy to understand for my teammates as well as my future self. Some ways I achieve this include using clear, descriptive and consistent naming conventions, documenting the purpose of code when the underlying decisions may not seem obvious and creating modular code that can be easily reused. As a final effort, I prioritize writing thoughtful commit messages that describe the changes I make to keep a written record in our version history.
I try to evaluate if my code will be easy to understand for my teammates as well as my future self.”
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
As engineers, sometimes we tend to overcomplicate implementations with unnecessary design patterns or libraries, which can impede readability and flexibility. Additionally, when pull requests and commits are really large, peer reviewing that code becomes more daunting, resulting in less thorough feedback. Lastly, failing to document code and track technical debt can create a codebase that is harder to maintain. Keeping maintainability in mind and getting feedback early and often can help prevent these habits.
How does your team make clean code a priority? What are the benefits of this approach to software development?
At theSkimm, we use code reviews and pair programming as a way to ensure readability and shared knowledge among team members. When possible, code is reviewed by multiple teammates and pull requests are not merged until code has been approved. Pair programming is helpful on large implementations or when making important design decisions at a low level.
As a team, we share a responsibility of tracking needed improvements and technical debt, and we prioritize a percentage of the work in each sprint to continue to enhance our code over time. We believe it’s important to carve out time in our product development process to make these improvements an ongoing habit.
andros
Tory Mance
SOFTWARE ENGINEER
Tory Mance, a software engineer at healthtech company CredSimple, said streamlining code blocks to prevent redundancy helps reduce bugs. Organizing code by following patterns allows others to hop in when updating or utilizing. Mance said open communication is essential for all of this to happen.
When it comes to writing clean code, what are some best practices you follow, and why?
Don’t repeat yourself. Having multiple methods or other blocks of code that serve the same purpose can cause problems when trying to debug an issue. This can lead to a bug being fixed in one place and not another. It also can lead to redundant tests. Keeping things consolidated when possible keeps things easier to read, reduces the amount of code and ends up saving you from doing extra work.
Follow patterns. Whether it’s naming, style or architecture, having distinct patterns in your code makes it easier for others to pick up work that involves updating or utilizing it.
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
Overreliance on third-party libraries. There are a lot of great libraries out there, but I think a common pitfall many developers fall into is relying too much on third-party code to get the job done. There are obviously exceptions, but in my experience, there usually comes a point where you need a library to do something specific to your domain that it just wasn't built to do. At that point, you’ve already invested a ton of time into supporting this library and now need to find a workaround. Not only that, but the more you rely on third-party code, the more bloated your codebase becomes with extra dependencies.
My rule of thumb for using a library is that it should solve a clear, concise problem and it needs to have a good amount of support from its creators.
We encourage feedback and empower employees to have open lines of communication when collaborating to ensure we are functioning effectively as a team.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
I think the biggest way we make clean code a priority is through open communication. This creates more opportunities for pair programming because such a culture allows developers to feel more empowered to ask for help. Similarly, if a code review brings up larger questions, we encourage setting up a group discussion to ensure a solution is agreed upon. We really value honest and transparent communication. We encourage feedback and empower employees to have open lines of communication when collaborating to ensure we are functioning effectively as a team.
Addepar
Gang Luo
SENIOR SOFTWARE ENGINEER
Gang Luo, a senior software engineer at fintech software company Addepar, values the power of comments in code. Comments should motivate, provide concrete examples and reference external resources for utter clarity. Concise code comments help make the review process more human-friendly.
When it comes to writing clean code, what are some best practices you follow, and why?
First, specific and meaningful naming is important. It provides a level of abstraction, hides implementation and calculation details behind variables and functions, and allows quicker and more precise comprehension of the code structure without unpacking every single "black box" and diving into details unnecessarily.
Having a dedicated class to represent and refer to all variables with meaningful names is a great way to solve that. What's more, an explicit "profile" provides a high-level overview. Is your class supposed to be singleton? Are you ready for someone else to extend your class? Is your implementation thread safe? Is it immutable? Those are important characteristics for people to understand the code briefly but precisely, and to use it properly. Be mindful of them and explicitly annotate and document them.
Finally, don’t overlook the power of comments. Don't simply rephrase code behaviors in human and natural language, but write comments that expand the context with motivation, concrete examples and references to external resources. Such extra level of detail and verbosity compensates for code that goes the opposite direction and is a critical part to promote friendliness to humans.
...Don’t overlook the power of comments.”
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
One common problem is to speculate the usage pattern and overengineer. More often libraries are conceived with some clear usage patterns, particularly in a smaller and cross-functional environment. Still, people feel they have to go beyond and implement everything just to make the code look "complete," even if they are not immediately useful. Or in cases where an IO component could be a bottleneck in the future but isn’t yet, it is not surprising to see some premature optimization being applied early just to make the code "scalable" or future-proof.
As much as those concepts (versatility, scalability) sound appealing, it creates problems. First, it is simply a waste of time worrying about the problems at the wrong time and wrong places. It also creates long-lasting debt to maintain the code and tests. Additionally, it makes the code more complicated with no immediate benefits. In the end, it is unlikely the implementation and optimization made today will be the right fit for the feature or performance required tomorrow.
How does your team make clean code a priority? What are the benefits of this approach to software development?
Engineering teams across Addepar take code review seriously. Reviewers not only provide an extra safeguard for code quality, but they are keen to learn more details behind the code change. It is not uncommon to see reviewers catching up with context, motivation and restriction as much as they are making critical feedback. Such cross-pollination is a great motivation and comes back to push the author to pay extra attention to code readability, clean it up and structure it right.
In addition to human power, we also deployed automated tooling to cover common and repetitive issues, from an IDE profile enforcing code style to pre- and post-commit checks with static code analysis tools. The two combined not only maintain a high bar for code quality but are great ways for every developer to learn from peers and real world practices. They also make the software development life cycle a more rewarding experience.
Prizeout
Brendan Grove
CTO
To write clean code at payout company Prizeout, CTO Brendan Grove said his team focuses heavily on collaboration. Whenever an engineer writes code, they consider the fact that another developer will be expected to work with it as well. Joint tech planning sessions allow teams to review outline and pull requests as well as expectations of themselves and each other.
When it comes to writing clean code, what are some best practices you follow, and why?
I believe understanding the problem space is a necessary foundation for writing clean code. I like to think about solving a complex engineering problem as exploring a dark room; you need to take the time to explore the nooks and crannies, really understand the shape of the room and constantly rethink what you thought you had learned before.
This type of learning and iteration allows you to define the responsibilities of various services and develop the structure of your program. From there, clean code is really about standardizing and replicating patterns that can be defined by the team and can be unique to any given company. Similar APIs should follow similar structures, database naming conventions should track across services and complex logic should be well commented for future developers. The challenge is balancing perfection with speed, especially for a startup.
Ultimately, I believe clean code is all about picking the right structure for the problem, finding the right home for all the logic and allowing future contributors to read your service like a textbook. They should know what page to turn to for the information they need, and they shouldn't be forced to read the whole thing to understand various modules.
Clean code is all about picking the right structure for the problem, finding the right home for all the logic and allowing future contributors to read your service like a textbook.”
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
I think the biggest bad habit is starting with a structure that doesn't quite work, learning more and then continuing down the same path. Usually I see that this ends with unnecessarily complex functions, hard-to-understand code and, ultimately, code that is prone to bugs. Code that feels too complicated probably is.
Two big pet peeves of mine are when logic seems to live across multiple services with no clear ownership between them and over-optimizations in the name of efficiency. Both make it hard to build on top of the foundation, with new features forcing changes in multiple places or the seemingly "efficient" code being hard to understand. Institutional knowledge then becomes a bit too relied upon. There is nothing wrong with a simple IF statement if it's clean, readable and gets the job done.
How does your team make clean code a priority? What are the benefits of this approach to software development?
Our team has a heavy focus on collaboration. We try to bring in teammates with various backgrounds and expertise, which allows everyone to learn from each other. It also ensures teamwork and that team members can contribute to the growth of others. I think this creates a feeling of responsibility to each other that encourages clean code.
If an engineer knows their teammate is going to have to work in the same codebase in the future, they will want to give them a foundation of readable and understandable code with which to start. That is what they will expect of others when they dive into a new codebase that they have never worked on before.
We also have joint tech planning sessions and team reviews of both tech plans and pull requests. We try to outline and document expectations ahead of time for what we expect from ourselves and each other. I really love this approach with a focus on collaboration and ownership because I think we have cultivated a team that loves working both together and for each other. At the end of the day, that's really why you want to write clean code.
Kensho Technologies
Aron Szanto
TEAM LEAD, NATURAL LANGUAGE PROCESSING
Aron Szanto, an NLP team lead at Kensho, a company that leverages data to develop AI, said they try to avoid artificial coupling of components. Artificial coupling can be avoided by being thoughtful and asking where a method, variable or class should reside, what parameters it should take and where it will be called. As well, using tools like Mypy and Black before review helps minimize errors.
When it comes to writing clean code, what are some best practices you follow, and why?
We insist on designing deep interfaces. Modules and classes should have few public methods, functions should have few arguments and provide sensible defaults, return types should be simple, and methods should do one and only one thing. This allows each capsule of code, big or small, to serve exactly its intended purpose while providing flexibility to extend or modify internal implementations transparently and at the proper level of abstraction.
One sign that a module's interfaces are too shallow is that its callers need to invoke multiple functions with many arguments to do conceptually simple things. Writing deep interfaces is the very best gift you can give your team and your future self.
Writing deep interfaces is the very best gift you can give your team and your future self.”
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
One anti-pattern we come across is artificial coupling of components. Coupling in software systems is a measure of the dependency between two modules. Artificial coupling occurs when functionally distinct structures are combined in code without a good reason.
Luckily, most forms of artificial coupling are easily avoided by asking “what does this thing I'm building actually need to know about?” when thinking where a method, variable or class should reside, what parameters it should take and where it will be called. A decoupled codebase is a happy codebase!
How does your team make clean code a priority? What are the benefits of this approach to software development?
Our team’s mantra with respect to low-level aspects of code quality is “don’t leave it to humans.” We use great tools like Mypy, Black, isort and Pytest to format, typecheck and test our code, before it's even proposable for review. These automated tools catch errors that even the most experienced engineers might miss. It also supercharges the effectiveness of code reviews when no one has to think about style, formatting, type correctness or other minutiae, instead letting themselves focus on the big picture.
At a higher level, we take care to manage and document the technical debt we accrue and be deliberate about whether its ROI, taking into account the cost of paying it off later, is still positive. We maintain a high code cleanliness bar, even when doing it right takes longer than doing it fast.
Last, we recognize that technical debt compounds when unaddressed, so we allocate strategic work time every month to allow ourselves to stop making immediate progress and instead return to areas where we made tactical tradeoffs in favor of expedience.
Radar
Craig Kochis
STAFF SOFTWARE ENGINEER
CTO Tim Julien said that location data company Radar’s clean coding best practices — like code reviews, writing tests and automated tools — are enforced in configuration to ensure engineers always follow them. Staff Software Engineer Craig Kochis and Senior Software Engineer Jeff Kao explained that tools can help keep the codebase clean and consistent but developers must still be thoughtful in their approach.
When it comes to writing clean code, what are some of the best practices you follow, and why?
“Whether it’s in the form of a linter like ESLint or static analysis tools like SonarQube that can catch bugs and security vulnerabilities, automated tools like these let developers spend less time thinking about how they should be writing code and more time solving the problems at hand,” Staff Software Engineer Craig Kochis said.
“On the front end, we leverage prototyping tools like Storybook to build our UI components in isolation before integrating them with the rest of the site. This lets us get quicker feedback on new designs and forces us to think about building components that are reusable in different settings. And as an added benefit, we have a growing library of usable and well-documented components that other developers can leverage in the features they build.
“I think it makes engineers understand the bigger picture of what they’re working on and why they’re doing it. Then, they usually have more empathy for the people who will actually use the product. So, they’re not just writing something and handing it off to someone else; they actually have to go through the steps of using it by going through the pain points themselves. And at the end of the day, that helps engineers build better products.”
...The code that you write at a company is not limited to just yourself; a lot of it is an exercise in communication.”
Jeff Kao
SENIOR SOFTWARE ENGINEER
On the flip side, what are some bad coding habits that you wish every developer would stop doing, and why?
“Generally speaking, the code that you write at a company is not limited to just yourself; a lot of it is an exercise in communication,” Senior Software Engineer Jeff Kao said. “You can easily write code in a ‘smart’ way versus a way that everyone can understand. You could write something ‘smart’ all in one line, but that can lead to mental overhead or cost for the team because they won’t be able to understand or work with it. That’s why it’s important to have empathy for your teammates when writing code.”
Tim Julien
CTO
How does your team make clean code a priority? What are the benefits of this approach to software development?
“We’ve configured Github such that you can’t push directly to master; you have to open a pull request,” CTO Tim Julien said. “Similarly, for security scans with SonarQube or functional tests, you won’t be able to merge to master until those checks pass. It’s freeing because you don’t have to remember to do it because the system just puts up those guardrails.
“To ship a feature to a customer, you’ll probably need to touch all of these. You don’t need to be an expert in every codebase but I do think that getting exposed to many languages helps you pattern match and pick up the idiomatic style of that language. For people who speak multiple languages, they talk about how each incremental language is easier to grasp because you get better at learning each time around. I think programming languages are similar.”
ArcherDX
Aaron Berlin
VICE PRESIDENT OF INFORMATICS AND COMMERCIAL DEVELOPMENT
No engineer wants to spend more time fixing code than writing it. Berlin said upholding high standards throughout the product lifecycle reduces time spent untangling messy code later. His team leans on automated tools, shared libraries and rigorous code reviews to ensure implementations go smoothly.
When it comes to writing clean code, what are some best practices you follow?
Our software group uses coding standards and automated tooling that enforces those standards. This allows us to keep a maintainable codebase where any developer can support and contribute, not just the original author. The use of linters and other automated tools allow code reviews to focus on implementation rather than poorly formatted or structured code. Additionally, our codebase has a large library of reusable components that reduces the opportunity for duplicated or divergent code.
The software group prioritizes clean code in all aspects of the software lifecycle, including development, testing and deployment.”
What are some bad coding habits that you wish every developer would stop doing?
The worst coding habits come from working in a silo away from the rest of the group. It invariably leads to code that’s difficult to understand and maintain by other members of the team — including the original author.
Also, when a developer chooses the newest technology without vetting it or considering how it fits into the current technology stack, we generally see code that fits poorly into existing expectations and paradigms.
On the code review side, pull requests with a large number of files are difficult to review and typically lead to lower-quality reviews and thus, lower-quality additions to the codebase.
How does your team make clean code a priority?
The software group prioritizes clean code in all aspects of the software lifecycle, including development, testing and deployment. During development, we use shared libraries, automated tools and multi-person review cycles. Our testing is automated and contained in our source code. The automation of the tests through continuous integration tools help keep the merged code accurate and bug-free, leading to less churn and fewer edits in the codebase.
Finally, our DevOps team uses tools like terraform fmt and predefined templates to ensure consistent formatting. We’ve even extended the clean-code mantra to our documents, which all live in-source next to the code and are rendered automatically with each build. Incorrectly formatted documents will block a merge in the same way as a failing test.
Alteryx, Inc.
Mike Williams
LEAD SOFTWARE ENGINEER
Clean code doesn’t just make other engineers’ lives easier but can also have a significant bearing on how customers respond to new products, Williams said. To keep customer — and engineer — satisfaction high, the data analytics software company relies on frequent testing and code reviews to check their work while they’re building new products.
When it comes to writing clean code, what are some best practices you follow?
We focus our attention on understanding how the code works in code reviews, which helps trap logic errors. New features get an architectural review early on. Any new architecture or modifications needed can then be diagrammed and accounted for in planning and provides clarity for developers.
We put a strong emphasis on using unit tests to validate the code. This is sometimes called test-driven development (TDD) or red-green-refactor. The tight loop of the TDD cycle — write test, make the test pass, refactor — enables our developers to discover edge and error cases faster and trap them at our desk. This speeds up development because it prevents future delays caused by finding errors later down the road.
By closely following best practices and processes we have in place, we have high confidence in our code when we send it out.”
What are some bad coding habits that you wish every developer would stop doing?
The most harmful development practice I have seen is deadline-driven development. This is a practice where a company specifies that a given set of features must be delivered by a specific date. Sometimes, the work is simply not ready when the date comes around.
When that happens, the company needs to either move the date for the entire release or release the majority of the new features on time and push back the features that are not ready. Cutting corners to meet a deadline results in serious customer-found defects. This can erode the trust that the customer has in the product and leads to a terrible customer experience.
How does your team make clean code a priority?
By closely following best practices and processes we have in place, we have high confidence in our code when we send it out. It is uncommon to find a defect in the happy path. If a defect is found, it usually results from unexpected use cases, integration failures or surprise edge cases — but these are easy to fix because of our high-test coverage.
CCC
Mike Wilson
SENIOR MANAGER OF WEB DEVELOPMENT
“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.
MobilityWare
Jesus Quezada
SOFTWARE ENGINEER II
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.
The Predictive Index
Travis Hervey
SOFTWARE ENGINEER
Hervey’s best practices for clean code: First and foremost, come up with a plan. Writing code without fully understanding the scope of the problem can lead to hitting unanticipated use cases. Or you can miss design requirements that may lead to shoehorning code into places it doesn’t belong just to get the job done.
Engineers get excited about writing code and want to jump right into it. Instead, we should take time to plan and ask probing questions. Understanding whether requirements go beyond what’s defined in the design specifications results in cleaner code. It also prevents devs from context-switching from a coding mentality to design mode, and back again. Sometimes additional requirements are uncovered while coding, but minimizing them up front — by planning for them during design — will help produce cleaner code.
Promote consistency in code by defining the best practices that will guide engineers.”
Habits devs should stop: Engineers sometimes don’t have a deep enough understanding of the frameworks they use, which leads to either unanticipated behaviors or poor software performance. Object-relational mappings seem to trip up new developers as far as understanding the performance impacts of queries generated behind the scenes. Frameworks are a double-edged sword: they make our lives easier, but only when we know how to use them appropriately.
In terms of clean code, use descriptive variable and method names. Nothing drives me crazier when reading and understanding someone’s code than keeping track of nondescript names. Avoid writing monolithic “do everything” classes. Keep classes succinct and remember the single-responsibility principle. A class should only do one thing, so make it do that one thing well.
How The Predictive Index prioritizes clean code: One of the most powerful tools, for both developing clean code and training developers, is the code review process. Experienced engineers providing meaningful feedback to junior devs evolves the next generation of coders who will educate others on best practices.
Don’t just point out what is wrong during code reviews; suggest options for improvements. I found reviews to be a transformational tool. They provide opportunities for growth, make me a better developer and improve the quality of my code. Promote consistency in code by defining the best practices that will guide engineers. If developers know what’s expected, they will save time refactoring code that doesn’t hold or scale to the organization’s expectations later.
Markforged
Bruce Jones
SOFTWARE ENGINEER
Jones’ best practices for clean code: My first recommendation is to absolve yourself of as much responsibility as possible and let your tooling do the work for you. Depending on the language, it is likely that there is a linter and a code formatter available. The combination of these tools will make code automatically consistent. They will take care of the low-hanging fruit, but it is still on the dev to write good code. To that end, I tend to focus on readability over performance. I only consider performance when code is not performing to the level it should. If code is easy to read, and formatted consistently, it should stay clean on its own.
Finally, make sure the code does what you think it does by writing tests. Tests provide confidence that the code works now. When refactoring, developers can run tests at every step and ensure nothing breaks and the code stays clean.
Not writing tests at all is asking for bugs.”
Habits devs should stop: Developers often try to make their code as concise as possible and sacrifice readability in the process. The most frustrating part of these efforts is single character variable names. If names were more specific, other engineers would immediately know the purpose of every variable on any given line of code. Single character names reduce devs to studying the context of every line to figure out intent.
Another bad habit is not writing tests. I have little preference between writing tests before or after implementing code. Depending on context, both approaches have their value. But not writing tests at all is asking for bugs. The best part about tests is that one can prove that the bug you just fixed doesn’t exist. So you can push code and never worry about that bug again.
How Markforged prioritizes clean code: Review isn’t something that just happens at the end of a job, and we have regular check-ins with reviewers. A development task typically has three stages: architect, implement and polish. A reviewer’s insights are valuable at every stage. I have often submitted code for review, naively seeking feedback on the polish type, only for a reviewer to suggest sweeping architectural changes that force me back to the drawing board. Reviewing at every stage of development leads to better solutions.
Buoy Health
Julia Giraldi
SOFTWARE ENGINEER
Giraldi’s best practices for clean code: Writing code feels like experiencing déjà vu; it’s important to see whether or not I’m repeating myself. I always take opportunities to reuse code I’ve already written. Also, look at comments and descriptive names from an outside perspective. Make sure names are appropriate and helpful for someone unfamiliar with the codebase.
We try to consider future cases when designing our databases. Keeping them generic avoids growing pains as our APIs evolve.
Make sure names are appropriate and helpful for someone unfamiliar with the codebase.”
Habits devs should stop: Code siloing. When an engineer doesn’t share their knowledge, they are limiting themselves because others cannot provide feedback. They’re also leaving the rest of the team at a disadvantage. Unobservant engineers sometimes don’t conform to formatting that everyone else seems to be following.
Refactor legacy code when there are opportunities. Making frequent, small changes while accomplishing other tasks allows teams to keep moving forward and improving code. Long names are debatable. Some say descriptive variable naming is important but if names become too long, they’re compromised by becoming unreadable. Also, make comments. You may know what a complicated function does today, but maybe not in six months.
How Buoy Health prioritizes clean code: All code is reviewed, and many projects require two reviewer approvals. We also maintain front and back-end style guides for engineers working on different teams. All of our devs are encouraged to suggest changes to these guides as the tools we use evolve along with the industry. We exchange ideas, search for feedback and ask questions.
We have regular engineering meetings where one or two engineers present on topics of their choosing. These presentations can be about internal changes we’re implementing, or they can share their knowledge on something they learned externally with the rest of the team.
Takeoff Technologies
Lam Bao Nguyen
SENIOR SOFTWARE DEVELOPER
Nguyen’s best practices for clean code: When I draft some functionality, I’ll rewrite it multiple times. Rewriting makes me examine many aspects of the code, such as how understandable my variable and function names are. But most importantly, it tells me how easy it is to change my code and check the result. I want code that’s easy to understand and safe to change.
Along those lines, tests give devs the confidence to work on the aesthetics of their code while delivering the same functionality. There are lots of philosophies on tests, but they should be written, and try to make them fast.
Lastly, make sure to understand the context into which your functionality fits. It could be something as simple as figuring out what happens downstream when an endpoint succeeds or fails. No amount of work to keep code clean will save you if you’re not solving the right problem.
If something goes wrong with our code, we always have someone on call to investigate.”
Habits devs should stop: Non-descriptive variable and function names, a lack of comments and unnecessary abstraction cause the code to be less understandable. Code could also be more easily understood if it was written more verbosely rather than condensing a bunch of logic into a one-liner, making the code overly “clever.”
There are also a few bad habits that can cause instability. These practices include coding so that multiple versions of the code can’t co-exist, not coding to allow for graceful version changes and not having a feedback loop or a tool to know whether functionality is working. Having good logs or metrics can usually solve this issue.
How Takeoff Technologies prioritizes clean code: If something goes wrong with our code, we always have someone on call to investigate. Providing support for production issues is a top priority for the team. Knowing it might be your turn to be called at 3 a.m. to resolve an issue makes the importance of writing good code very real to us.
We make sure to have appropriate reviews and testing for our code. To help improve contextual knowledge around the things we are building, we pair up, hold learning sessions and temporarily embed ourselves on other teams. The key here is to take active steps in figuring out what works best for the group by reflecting, and improving.
Alert Innovation
Kevin Ghozati
SOFTWARE SQUAD LEAD
Ghozati’s best practices for clean code: I spend a great deal of time thinking about the problem domain and how it’s modeled by nouns and verbs. As an engineer, I think through and solve problems using these abstractions. I can intuit a lot about the solution by modeling the abstractions properly. Clean code reads like a well-written, concise piece of literary work. I keep my methods and functions short and cohesive to keep the reader focused and ensure that the work is being done at the same level of abstraction within that body.
Finally, I make use of functional programming techniques whenever I can. By composing functions out of more atomic elements, I can build flexible pieces of software and reuse those pieces to solve more complex problems. Brevity is king with software.
Clean code reads like a well-written, concise piece of literary work.”
Habits devs should stop: I wish developers gave more thought to naming their variables, methods and classes. I’ve seen methods named “do_it” in an interface that was implemented by nearly 20 classes. It’s not that these names are wrong or misplaced. But sometimes something could be a curator or a horologist that could help frame a problem better to the uninitiated reader, or to me nine months later.
Additionally, I wish developers would restrict access as much as possible with their variables. Declare a variable as constant when it should be constant. The same goes for methods, functions and classes. By being disciplined and thorough, you will catch bugs much faster than you would otherwise.
How Alert Innovation prioritizes clean code: My team makes clean code a priority through vigorous code reviews and trying to learn as much as we can from one another. We automate as much as we can and have pretty stringent linting rules. When code comes up for review, there is already a baseline set by our tools that helps keep the review focused on functionality and design. By following these practices and principles, we are able to ensure high software quality, which means less bugs to fight in production.
Mimecast
Dan Conn
SENIOR SOFTWARE ENGINEER
Conn’s best practices for clean code: Our best practices make code easier to read by starting with the fundamentals. Methods that do things should be phrased as verbs, while methods that return a boolean can normally be phrased as a question that reads naturally. Variables and class names should explain why they exist in a concise way. Functions should have one intentionally-focused area of concern.
These clean code fundamentals help to make your code look like language phrases, and then everyone has a better understanding of the project. When you are coding complex projects, especially when maintaining them, that ease of readability definitely helps.
If we try to use these tools inappropriately, things will get hard to read very quickly.”
Habits devs should stop: I think there is a tendency for us to forget that code is a tool. We tend to favor the languages, frameworks and paradigms we know and sometimes try to use them in inappropriate ways. Neither object-oriented programming, functional programming, nor procedural are always correct. People will pick React or Vue as their framework of choice but sometimes jQuery might be good enough. Or someone might choose jQuery where a more modern framework could get things done quicker. If we try to use these tools inappropriately, things will get hard to read very quickly. When things flow, they’re easier to follow.
How Mimecast prioritizes clean code: We have a set of principles called “The Mimecast Way,” two of which are “make things better” and “invest in one another.” We have diverse team members in the UK, USA and New Zealand. We invest in one another — and build cleaner code — by sharing perspectives and looking for common understanding. Pair programming via video chat and code reviews help us discuss code flow and naming conventions. Our main focus is determining whether better words could be used to describe a situation for everyone that needs to read it.
H-E-B
Claire Lee
SENIOR UI ENGINEER
When it comes to writing clean code, what are some best practices you follow, and why?
Clean code is easy to understand and maintain. Using meaningful names helps clearly convey purpose. It’s easier to remember what a variable named “description” does than one named “d.”
Having good conventions for code structure and organization improves code readability and decreases risk and frustration when making updates. This idea includes having small, focused functions and data structures with easy to understand roles and responsibilities.
Code reviews are a good place to advocate for and learn about good programming habits.”
What are some bad coding habits that you wish every developer would stop doing?
Many bad coding habits stem from overvaluing personal preferences or ability. For example, writing code that doesn’t conform to the styles that a team agrees upon makes it harder for other developers to understand and work with that code. Premature optimizations or attempting to write a custom solution — when a tried and tested one exists — can lead to code that’s more difficult to update and maintain as business requirements change.
How does your team make clean code a priority?
We seek feedback from one another and work to improve as a team. Code reviews are a good place to advocate for and learn about good programming habits. They also help ensure the entire team is in alignment.
Additionally, we have chat channels and meetings where we’re encouraged to bring up broader questions about our technical approach and coding patterns. Having an environment that fosters asking questions and sharing experiences has helped us grow as an engineering team and as individuals.