Clean coding: Clean coding has recently become among the most popular threads of the software world. Well, it deserves to be so. We, as programmers, generally hear below expressions (or complaints): – I took over a mess. – That is a very complicated code – Why did s/he do that here? – If I touch it, it might as well blow up. Let’s begin by confessing something: It is possible to come up with a working code, albeit with some delay. You might happen to happily have a working application by copying code that serve similar purposes, by Googling it, by getting some help, if not, by trial and error. Yet the problem starts right at that point:
- How simple and readible is the code?
- Have you sufficiently handled exceptions?
- Did you pay attention to performance?
- What about duplicate code?
- Are there any dependencies?
- Has memory been effectively used?
A negative answer to one or more of these questions would generally be enough for the code to have a short span of life. Or you might as well end up talking about retirement or refactoring, which are all expansive affairs, as we all know. That’s why clean coding is essential. Clean coding is not a technological problem. It is rather an architectural problem, and it is related to how well a programmer does his/her job. It is difficult to explain, yet we might roughly define it as “having a simple, readable, efficient structure or pattern” It doesn’t depend on the programming language that is used by the programmer.
How do we recognise that a code is not clean enough and we need refactoring?
Refactoring is generally required when you touch the relevant code block for an amendment, when you have a performance problem or when a defect appears. In such cases a need for testing the changes is an acceptable outcome, and the contact would be ready for that. But when you decide to refactor out of the blue, you need regression tests, and an analyst/tester contact is required, which creates extra cost especially corporate companies won’t be willing to pay. There are certain signs which indicate that the code you are working on needs refactoring. Experienced programmers can easily recognize them. Below are some of these signs: – Too many loops or conditions nested in one another. – Meaningless variables, methods or category names – Methods or functions with too many parameters defined – Fat methods, classes, code blocks – Repeated (duplicated), copy pasted code – Redundant comments – Insufficient exception handling When you recognize one or more of these indicators, you might talk to your team (or squad) about a technical debt, and ask for planning (or adding to the backlog).
What should I keep in mind before and after refactoring?
Any refactoring, whether big or small, includes a risk. Here are some tips to take into consideration to minimize this risk: – Do not disregard unit tests. This is one of the most significant principles of clean coding. It both reduces the chances of the code to break and greatly facilitates the work of subsequent developers. – An analyst or test contact must be assigned for regression tests. Make sure to let him/her know about the amendments you have made or any suspected issues. – Get someone to make a code review. It is always good to have a second opinion. – Try to proceed in small pieces as much as possible. Big chunks of refactoring will not only be risky but also increase the cost of testing. – Deploy the changes to test environments and keep them there for a while if possible. Move to production later on. You will then have a chance to test many different cases. It might be acceptable for a new function not to work properly, yet breaking an existing function might lead to a crisis. – Make sure to have a backup plan. – Read and practice a lot. 
Clean Coding practices
If you do not want to experience refactoring, code crash or code retirement frequently, it is a must to learn and apply clean coding practices. After having introduced clean coding, working code, refactoring, technical debt etc. we can now dwell on clean coding practices. It will be more useful to deal with this very comprehensive issue in a series of blog posts. See you in our next post to cover the first practice, namely Naming Conventions.
Software Developer & Data Analyst
Always trying to understand the big picture in all projects he takes part, Necmi never hesitates to ask the question “why?”. He likes listening better than speaking. After 15 years of experience on back-end and infrastructure development projects, lately he started to get into data analytics and artificial intelligence concepts.
Can’t spend a day without a podcast. Plays daf amateurly but nobody listens. He likes to be frank. Condemns people who neglect sport and books.