When Levi9 developers took over an 8-year-old mobile application, they discovered a codebase so complicated that the entire team began avoiding working on it. With no documentation and class definitions spanning 3000 lines, the team was terrified of making even minor changes.
“There was nothing explaining the application’s specifications,” remembers Tiberiu Grădinariu, Mobile Tech Lead at Levi9. “For a developer who wanted to work on this application, there was a genuine fear of changing anything because they didn’t even know what the end goal was supposed to be.”
Although this was not a usual situation, the increase of bloated AI-generated code is making this scenario happen more often. As developers race to provide features faster by allowing tools such as ChatGPT to generate large portions of code, codebases tend to become bloated and poorly organized. For a weekend vibe-coded project, this might be fine, but for a long-term enterprise project, the approach is dangerous and unsustainable.
Clean code used to be considered a best practice, one of many. Now, it’s a critical skill for AI-assisted development. As the role of developers transitions from primarily writing code to curating, editing, and refining AI-generated output, the principles of clean code become the essential toolkit for turning fast output into safe, understandable, and sustainable software.
Based on Robert C. Martin’s book, Clean Code: A Handbook of Agile Software Craftsmanship, Tiberiu provides some practical techniques that busy developers can implement to improve code quality and longevity in AI-assisted development.
What is Clean Code?
How do we know if our code is clean? “A very nice notion that’s half funny, half very true”, mentions Tiberiu, “is when we read code, how many times do we slap our face in disbelief per minute? That’s basically the only metric we can apply.” Other definitions include code that reads like a good book or is precisely what you expect.
Clean Code Means Longevity
“Clean code isn’t written for ourselves as developers,” Tiberiu emphasizes. “If it were, it would be very easy to write and we’d want to do it because we’d get immediate benefits. We take the time to clean up code for others. It’s done by someone who cares about their teammates and the product.”
Tiberiu believes that “clean code” could actually be a synonym for “quality code.” While AI can write code fast, it’s the human developer’s responsibility to ensure that code is trustworthy. This is a job only humans can do, at least for now.
Companies looking to develop long-lived enterprise software while racing to release it, should also take some time to invest in editing and proofreading the code, with an eye towards the future.
“In the short term, everything seems fine – we delivered our story points for that sprint, everyone is happy at the end of the sprint, the demo of the happy path works, and tests pass because we didn’t write comprehensive ones,” Tiberiu explains. “But in the long term, the product will accumulate so much technical debt that nobody will be able to work on it anymore.”
The Basics: Names, Comments, and Functions
Naming is the First Line of Defense
Names are perhaps the most immediate way to improve code quality and AI naming should be particularly scrutinized, as LLMs tend to default to generic wording. Tiberiu emphasizes that “we should use names for variables, functions, and classes that express the intention we have.”
Follow these principles:
- Use names that reflect intention: Choose names that explain why something exists, what it does, and how it's used
- Avoid noise words: Terms like "info," "data," or "model" often add nothing to the meaning
- Be consistent: If you decide to use "fetch" for retrieving data, use it everywhere; don't mix it with "get" or "retrieve."
- Use one word per concept: Choose a word for each concept and stick with it
“The purpose of giving relevant names is that the code we write should represent the project’s documentation,” says Tiberiu. “If a variable is named ‘numberOfTasks,’ it’s clear what it signifies without additional explanation.”
Delete AI’s Verbose Comments
Comments are often overused or misused and AI code is peppered with redundant explanations. According to Tiberiu, “We should only add comments when we can’t express our intention through code.”
In clean code, comments are only necessary in a few cases, such as legal notes (copyright, licensing) and informative comments (explaining formats or external constraints). Excessive commenting should be avoided for several reasons, including the fact that “comments must be maintained as up-to-date as the code itself,” Tiberiu cautions.
Functions Should Do One Thing
“The idea behind functions is to specify several steps for a larger concept,” explains Tiberiu. What he means by that is that functions should decompose a larger concept into a set of steps at the next level of abstraction.
The Clean Code book outlines some key principles for writing functions:
- Do one thing only: A function does one thing if you cannot extract another function from it
- Use few parameters: Zero is ideal; three maximum
- Don't pass boolean flags: Create two separate functions instead
- Return something OR do something: Not both
- Minimize indentation: Ideally zero, maximum two levels
“A function that has an if-else doesn’t do one thing – it does two things,” Tiberiu points out. “It handles both the true case and the false case. Similarly, a function that evaluates a switch with all its cases doesn’t do one thing.”
Why Style Matters
Formatting Means Readability
Formatting might seem like a superficial concern, but consistent formatting makes code dramatically more readable. Tiberiu advises on the following:
- Limit file size: Maximum 500 lines per file
- Limit line length: Maximum 120 characters per line
- Declare variables close to usage: Don't declare all variables at the top
- Keep instance variables at the top of the class
- Place caller functions above callees
- Group similar functions together
“Concepts should be separated within a class,” says Tiberiu. “Public methods that call private methods should be one after another, and functions that perform similar operations should be in the same area.”
Objects vs. Data Structures
When designing data displays, developers must consider who will see it and what they need. “If we expose data from a vehicle, like fuel tank capacity and how many gallons are currently in it, someone interested in how much fuel remains needs to perform a calculation. But if we know that’s the requirement, we can expose the data directly in that format so whoever receives it doesn’t need to process it again.”
Preparing for Things Not Working Out
Errors Happen: Throw Exceptions
Error handling can make or break code readability. Clean error handling follows these principles:
- Throw exception instead of returning error codes
- Define exceptions based on needs; don’t expose all possible exceptions
- Don’t return NULL: throw exception or return special case object
- Don’t pass NULL as an argument to functions
“It’s preferable not to do error handling using return codes,” explains Tiberiu. “In a function that receives an object with an error code, you’ll need to handle many cases, checking for successful execution and various error conditions.”
Instead, Tiberiu advises throwing exceptions and only having two paths: the happy path in the try block and error handling in the catch block. “Don’t expose all possible exceptions. If you know that any exception in an API will be treated the same way, map them all to a parent exception and throw that instead.”
Limit API Exposures with Boundaries
When working with code we don’t control, like third-party libraries, developers need to be careful:
- Don't expose more API than needed: you should provide exactly what the users need, nothing else. Otherwise, you might have security risks
- Wrap third-party libraries: Create adapters that expose only what your application needs
- Use the adapter pattern for the yet unknown code: Define interfaces as you expect them to work, then adapt them to actual implementations
This approach is particularly valuable when integrating AI-generated code, as it allows you to define clear boundaries around potentially unpredictable implementations.
Keep Classes Focused
“A class that doesn’t do a single thing is common, especially in mobile development,” Tiberiu notes. “Often we have a screen and put all the logic in one massive class instead of splitting it into multiple classes with distinct responsibilities.” While he can empathize with this manner of approaching code writing, Tiberiu says that, according to clean code principles, classes should follow several rules:
- Single Responsibility Principle: The name of the class should directly and clearly reflect the one thing it does
- High cohesion: Methods in a class should use as many of the class's variables as possible
- Open-Closed Principle: Classes should be open for extension but closed for modification.
“When you modify a class, you might break something or need to retest it completely,” warns Tiberiu.
Even though the fundamental book on clean code was written in 2008, the principles remain even more valid today, in the era of ChatGPT-generated code. As developers move from being code writers to being code curators, reviewers and proof-readers, the ability to code cleanly is a guarantee that enterprise projects can be handed over and maintained by multiple developer generations.
In this article:
Mobile Tech Lead
Levi9
