Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as primarily opinion-based by gnat, thorsten müller, Dan Pichelman, Kilian Foth, Bart van Ingen Schenau Aug 4 '13 at 16:34

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. –  gnat Aug 4 '13 at 14:49
2  
I don't have a very high opinion of that book (despite its author). In general it pays not to be too dogmatic. Most programming recommendations are because they have been shown to work in practice, but they are not the absolute truth, so don't worry too much. Keep reading and go with what you feel is more correct, but don't reinvent the wheel either. Chances are someone smarter than us has already figured out better solutions than our own. –  Jubbat Aug 4 '13 at 22:45
2  
A method with a 70 character name probably does more than one thing. SRP violation am I right?! –  Tombatron Aug 5 '13 at 1:03
1  
Here's another thought, 5 or 10 years from now when you are a developer at a company that could care less about clean code, you'll really appreciate this dogmatic exercise. –  Tombatron Aug 5 '13 at 1:06
1  
Having worked (briefly) under "no comments", I very much prefer it to be a strong guideline than a rule. There are times when comments are needed - usually in obscure business logic. A method called CalculateFoonicityMetric() tells you exactly what it's doing, and well-written code will show you how... but neither of these tell you why. Code can be obvious in what (multiply this by that, divide by the other thing, square it, add on this bit...) but unclear in why (factor = a*b/c; square to account for negative foo, adjust for drift...). I appreciate a quick comment that explains why. –  anaximander Aug 5 '13 at 11:02

2 Answers 2

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.

share|improve this answer

I was originally writing a comment. I'll try to give less of an answer than perspectives to consider.

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. Does this result in code that does only what is require or that has less bugs. What effect does this have on productivity?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.