Do You Have What It Takes To Be A Good Programmer?

A Clean Code Approach

Even the most experienced software engineers can feel like frauds sometimes. “Do I know enough? Is my code good enough? Can this be improved? Is the client happy with my solution? The client might be satisfied, but am I happy with how my code looks?”

While questioning yourself and your coding skills can be beneficial at times, you need to have confidence in yourself. So, if you’ve ever asked yourself these questions or if you simply feel the need to further improve your coding skills, give yourself a boost with the following clean code principles:

1. KISS — Keep It Simple, Stupid!

Clean code is written in a simple and easy to understand manner. Moreover, an application’s order of execution should always be logical and clearly structured. Therefore, every programmer should follow the KISS principle and avoid unnecessary complexities. One task can have multiple implementations, however, the simpler the code, the better and easier to understand it becomes.

2. DRY — Don’t Repeat Yourself!

Code should not be redundant, duplicated or difficult to maintain. By keeping it DRY, amendments to any component within a system doesn’t require making changes to any other logically unrelated elements.

Remember: stay DRY, not WET (We Enjoy Typing). For instance, rather than having unnecessary repetitions in your code, consider extracting it into a method and reuse it in multiple places whenever necessary. However, the connection between different parts of a code should be obvious.

3.YAGNI — You Aren’t Gonna Need It!

Code should be minimal and additional functionality should only be introduced when required. Therefore, if it’s not needed, delete it. Short classes and methods, well divided and on point are the key to a pleasant and easy to read code. It’s important to react to problems dynamically and individually by solving them in the most efficient way possible. Consequently, the role of each class, method and variable must be immediately comprehensible by avoiding unnecessary ambiguity.

4. SOLID Principles

Any good programmer writes code with the SOLID principles in mind:

– Single Responsibility Principle

– Open-Closed Principle

– Liskov Substitution Principle

– Interface Segregation Principle

– Dependency Inversion Principle

By following the above, clean classes with well organized APIs are written.

5. Design Patterns

There are many interesting design patterns to follow, however, good programmers know to choose wisely based on the problem they are trying to solve. The best design pattern is the one that leads toward achieving SMART* objectives in a simple and timely manner.

*SMART — Specific, Measurable, Achievable, Realistic and Timely

6. Minimal Dependencies and Easily Extended

An application should be loosely coupled since the more dependencies it has, the harder it is to maintain, amend or extend. Not only does clean code help achieve this goal, but it also makes reading your code pleasant for other developers. Thus, no time is wasted with trying to understand the author.

7. Expressive and Straight-forward

Expressive code helps people understand your work without the need to go through any documentation. Readability is vital as there is no point in writing concise code if other developers cannot understand it. Therefore, the following steps should be considered:

  • Use self-explanatory variable and method names: var d; doesn’t help anyone
  • Be consistent with naming conventions
  • Make functions discernible: Keep them as short and conceptually clean to understand as possible
  • Think twice before adding comments: Should the need for comments arise, maybe your code is in need of some further refactoring
  • Don’t hardcode: Code should be as dynamic as possible, thus, making it easy to change even if used in multiple places
  • Class and object behavior should have single responsibility: Avoid using ‘And’ in a method (CreateAndUpdate), create two new ones instead (Create and Update)
  • Don’t avoid code reviews: Their role is to improve code readability/quality, to promote knowledge sharing, to detect bugs and achieve higher accuracy in terms of sprint planning and task estimates, to name just a few.

6. TDD Approach — Unit and Acceptance Tests

TDD (Test Driven Development) is fundamental in writing clean, stable and consistent code. This approach leads to less or easier debugging, helping programmers ensure their code can be maintained and extended without causing any problems anywhere else in the application.

There are three laws to be considered for TDD according to Robert C. Martin, author of Clean Code: A Handbook of Agile Software Craftsmanship:

  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.1

In addition, Martin states that “The really effective part of TDD is the size of the cycle, not so much whether you write the test first. The reason we write the tests first is that it encourages us to keep the cycles really short.”

Therefore, firstly, unit tests ought to be written beforehand so that new functionality and behavior are understood before being built into the system. Once a line of a failing test is written, one should write the corresponding line of production code to make it pass. Secondly, development should be done incrementally — after writing any lines of code, a good programmer gets feedback via compilation or test run. Lastly, enough production code should be written to make the failing unit test pass.

The story of how Robert Martin arrived to that conclusion leaves most programmers with a lasting impression:

“I sat with Kent Beck (the father of Extreme programming (XP) and of TDD) in 1999 and paired with him in order to learn. What he taught me to do was certainly test first; but it involved a more fine-grained process than I’d ever seen before. He would write one line of a failing test, and then write the corresponding line of production code to make it pass. Sometimes it was slightly more than one line; but the scale he used was very close to line by line. […] I, and many others, have written about these three laws over the years. They now appear in many different styles, formats, and injunctive statements. But the goal is always to promote the line by line granularity that I experienced while working with Kent so long ago.” — Robert C. Martin

Clean tests should also follow the FIRST principles:

  • Fast: Tests should be fast in order to be run frequently
  • Independent: Tests should be run independently to one another
  • Repeatable: Environment should not be a factor of success when running tests; whether it’s a development, QA, or production environment, tests should be successful
  • Self-validating: The end result should be true of false; tests either pass, or fail
  • Timely: Tests should be written for a single functionality at a time and in a timely manner

The following quote should be food for thought — “If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?” — Scott Ambler2

Some programmers may wonder, why bother using these principles when it’s easier to work quickly and just get the job done? Consider the following quote by Martin Fowler, well-known software development speaker and author:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Still not convinced? The rationale listed below might change your mind:

1. Improved Skills

Committing to writing clean, quality code day in and day out can do wonders for your career in the long run. If done right, it is not time consuming. But, if it is, you will greatly improve your time management skills.

Co-workers enjoy working with programmers who write clean code and clients have confidence in their skills. There is, of course, always room for improvement and there will be many opportunities to refactor and improve your code. However, with such a mindset in place, the process will become easier and more enjoyable. Also, once the code is the best it can be, you can start working on more complex issues, such as upgraded performance and security.

2. Wasting Time Is History

Have you ever looked at some lines of code that you just can’t understand? And when check out the file history you realize,”Oh, it was actually me who wrote that. What was I thinking at the time?” It happens to the best of us, and the solution is simple. Having clean lines of code not only enhances readability and makes it easier to understand, but also ensures a smooth process when applying changes or adding extra functionality.

3. Appreciative Fellow Programmers

Some people find it a bit challenging when changing jobs — new colleagues, new venue, new project to work on. This is where the ramp up period comes in, enabling new team members to accustom themselves to the new environment and application. Having clean lines of code that require no documentation to understand and follow quickens the process and saves time for both the new hires and for their work mentor. Plus, you might even be thankful for your past self when you inevitably need to go through some of your old code.

4. Debugging Made Easier

Creating and fixing bugs is part of a programmer’s life. It is unavoidable, no matter your level of expertise. Clean code makes debugging a little bit, if not a lot, easier. And who doesn’t love easy, straight-forward debugging?

5. More Efficient and Cost-Effective Maintenance

In general, projects tend to scale up, which involves investing a lot of money into new features or amending the existing ones. Maintenance is one of the reasons why an application has to be as decoupled as possible and this can be easily accomplished by having a clean, well thought out and structured solution. One word of advice — do it well the first time and save yourself a headache the second time.

6. Feeling proud

The quality of your work differentiates you from a simple programmer to a good or even excellent one. Experience comes with time, but having a positive mindset and guiding yourself by good principles can be done from the very beginning of your journey.

Writing clean code is a first step in the right direction. Before long, your commitment and hard work will pay off, making you feel proud and good about yourself. So, why not start now? Adopt a clean code approach and you will not regret it.

Sources

Works Cited:

  1. Martin, Robert C. “The Cycles of TDD.” 2014.
  2. Ambler, Scott and Lines, Mark. Choose Your WoW: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. 2019.

Some additional recommended sources to learn more about the clean code approach:

  • Clean Code: A Handbook of Agile Software Craftsmanship (Martin, R., 1st Edition, 2008)
  • The Clean Coder: A Code of Conduct for Professional Programmers (Martin, R, 1st Edition, 2011)
  • Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Martin, R., 1st Edition, 2017)
  • Refactoring: Improving the Design of Existing Code (Fowler, M., 2nd Edition, 2018)
  • The Pragmatic Programmer (Thomas, D. and Hunt, A., 1st Edition, 2019)