Are “Clean Code” practices really that clean and useful? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

I am currently doing an internship in a large corporation and they are undergoing many changes in software delivery structure (moving to Agile).

In the past couple of months I have noticed this religious attachment to Clean Code practices and the book being like a bible for the developers.

Now, one of the most important features of the clean code is self-explanatory code which is based on understandable naming and rigorous re-factoring. This is followed by no commenting rule.

I understand that this clean code is a long term investment which will ease following code maintenance and improvement, but... is this really worth all this fuss?

Would anyone share their experience on Clean Code and any opinion whether I am just too conservative or it is just a temporary trend.

Answer 1

I understand that this clean code is a long term investment which will ease following code maintenance and improvement, but... is this really worth all this fuss?

Absolutely.

Re-factoring is very important, but spending 75% of your time moving the methods and spending loads of time to decide its proper title does not seem to be that productive.

Sure, but consider that the large company probably has years or decades of bad code to clean up. It's going to take a lot of time and effort to do that.

The main thing to realize is that you're both right. "clean code" is very important, and Clean Code is a universally respected way to get there. Since the company has just started along the path, they're going to be beholden to the book more than a group that has more experience. Once they've done it for a short while, they'll begin to learn what works and what doesn't. Once they understand that better, they'll (hopefully) follow a more pragmatic and natural approach that maintains clean code, but doesn't lead to 70 char function names.

Answer 2

I was originally writing a comment. I'll try to give less of an answer than perspectives to consider. However, I absolutely endorse "Clean Code" practices like understandable naming and refactoring.

I've always disliked the no comments rules, as there are cases where comments are necessary to prevent future code breakage. They normally should be restricted to what is being done and why. Use them sparingly when the code is doing something unexpected, or an algorithm needed to be replaced.

Consider productivity when you are reading or maintaining code. In the lifetime of the code, this may be more important than productivity when writing the code. Will these practices help productivity in these tasks?

With experience, these practices should become ingrained, and less of a productivity killer. Choosing the right name may take longer because you are clarifying what the code needs to do. (This clarification may make coding and debugging go faster.) Does this result in code that does only what is require or that has less bugs? What effect does this have on productivity?

The time taken in choosing the right method name will likely pay off immediately in better understanding what the method's purpose is. Compare the method names "iterateOverCustomers" to "locateActiveCustomers". Which one conveys the intent of the function? Which one will be easier to refactor if necessary?