Software Quality: “Clean Code”

My name is Khondoker Yasin Ahnaf Prio and I am a Computer Science Major at the University of Minnesota. I love quality good software! I enjoy using them and I enjoy being in college thriving to be someone who one day who will develop them as well. This is going to be the first of many articles where I talk about thriving to learn to be exactly that and the first one is about writing “Clean Code” and why is it important.

What do people mean when they say you should write “Clean Code” when they say that’s what you should be doing if you want to make good quality software? To understand that more in depth I am currently taking a class about Measuring and Maintaining Software Quality and this is what I understood after reading just the first 15 pages of a book by Robert C. Martin named “Clean Code: A handbook for Agile Software Craftmanship” which I recommend people to read as well as it is an excellent read in some aspects.

Martin starts by talking about why he thinks there should exist a reason for a book to be about writing clean code. He talks about how people told him that code will soon be obsolete and we will reach an era where business people will just be able to formulate and come up with software solutions by simply imputing what their requirements are. What he talks about makes me wonder if thinks one day the entire software engineering process will turn into a black box where you input what you need and the black box will spit out a software that does exactly that! There will be no coding involved what so ever nor there will be a software engineering cycle that comes up with the solution/product.

Martin then argues that it will never happen and that’s why there shall be coding, hence the need for people to learn about clean coding. Code is where all the details and the beauty of automating or creation of technological solutions take place. I really believe the intricate delicate specifications of the ways of problem solving specific to what needs to get done can never be achieved by a black box and that’s why we need to be really good at writing code that achieves to solve these problems.

Why should we take the time to sit down and just “Hack” away and writing huge chunks of code that get the job done and are not efficient? Cause we just should not. Code lives on. We should always understand that code we write will not only be expected to solve problems for just the present but also the future! We should understand that unless we put time and effort for people to maintain it, build on top of it: the code will soon die. That is exactly what happens cause technology is moving in such a fast pace that there is no other way that can be prevented. If you are writing code for machines to implement and solve a problem very rarely will you be having the time to write everything from scratch. There will be modules that you will be building on top of. Why? Because it gets the job done the best way possible and someone put the effort to take care of that for you to focus on other more important things. (BIG YAY! TO ALL THE OPEN SOURCE SOFTWARE/FRAMEWORKS WE USE EVERYDAY) We should be extra careful that we understand that these modules might move on to the next level and unless you have given space for that to happen for your software to do that as well things will turn nasty really soon.

If you write code that is not “Clean” and no one but you understand what it does you’re probably doing something wrong. Bjarne Stroustrup, inventor of C++ and author of the C++ Programming Language talks about how he like the code he writes to be “elegant and efficient”. He talks about how he believe the logic behind the code he writes should be straightforward to prevents bug to hide, have minimal dependencies to ease maintenance, and have performance close to optimal.

There are other people like Pragmatic Dave Thomas and Andy Hunt who like to describe this by the usage of a metaphor about a house with broken windows. The house is the software you are developing and the broken windows are the pieces of code you wrote which were so full of bugs or maybe so complicated that after sometime no one understood it anymore and so did not want to deal with it. One might argue a house with one or two broken windows does not mean we should build another house. But what this actually does is it gives them the opportunity for other windows to be broken as well. Before you know it all the windows are broken and it’s winter and your house has snow all over and have caused everything to fall apart. Now you do need to make a new house!

Dave Thomas, founder of OTI, godfather of the Eclipse strategy talks about how he thinks clean code is something that can be read and enhanced by a developer other than its original author. He emphasizes on why he believes that it should have meaningful names, units and acceptance tests. I agree, and as Martin talks more about it as well: test driven development has truly been something that has given really good results in software development and is something we should not ignore. Dave also talks about how he prefers code that is small rather code that is large.

Michael Feathers, author of Working Effectively with Legacy Code talks about how he believes clean code is code that looks like it something that you can look at and you can see it that it was something someone put the effort one and CARED for. It is code that looks like it was left by someone who cares deeply about the craft! I could not agree more about this. You can look at a function and when it starts by listing all of possible outcomes been considered you just know this was written by someone who put the time and effort to write elegant art that will make the software actually worth it.

Ward Cunningham, inventor of Wiki, talks about how he believes you can call it beautiful code when i makes it look like that the language was made for the problem. I like this way of reasoning! I like how Ward talks about when you see a piece of code you can agree that’s what you expected it to do and does it exactly that, not beating about the bush. However, I disagree, that not all code can be looked by someone and register the feeling of that specific thing was what the reader was looking for code. I’m talking about how it’s still beautiful and actually better cause the code captured something you weren’t going to account about thinking. The person who wrote the code clearly cared enough to that much detail they accounted for every possible worst or best case.

One of the best thing Martin brings out is how the ratio of reading to writing code is 10:1, so before writing any new code we actually are researching and reading code more. Make the reader worth their while, and give them the space to spin up something on top or side of it. Good clean code was not just wrote good but actually read about as well.

I would like to end the article by mentioning how Martin talks about the Boy Scout Rule, which is “ Leave the campground cleaner than you found it”. When you are working on a piece of legacy software make sure you leave room for someone to do the same thing you are doing right now! Code that just simply got better as time passed is the dream !

Khondoker Ahnaf Prio

Written by

I have an active interest in DevOps and Software Architecture besides being a full stack developer with an emphasis on Front End (ReactJS)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade