re: Identifying the dirt in our code - names, functions, and comments VIEW POST


Great material. There's a lot of legacy code out there that is violating a lot of these rules and a lot of developers are shaking their heads trying to understand the flow.


Every day I bump into some code that violates one of those principles.

(and almost every week I receive a code review that I'm the one doing this. I think that write clean code is something that you get used with time)


Na, clean code is not a thing you'll ever achieve. The principles you're working to are always going to be wrong one day or another. It'd be better to call then suggestions instead.

See, having "small functions" might be a principle, but a single 100-line function is much more understandable than those same 100 lines split into 20 5-line functions. Your ability to grok the code diminishes with every jump away from the block you're working with. the same with swich v polymorphism - it may sound fantastic in principle to a student, and simple examples "prove" it, but in the real world the large codebase built on polymorphism can be next to impossible to understand. I've been there!

Your best, and possibly only, means to mitigate every bit of "unclean code" is the thing you already said is considered harmful. Comments.

Comments are the documentation you never write anyway, they are the primary assistant standing between a mess of code and human understanding. Sure, you shouldn't litter your code with pointless comments, and sure you should treat your comments as if they were code themselves (ie keep them updated) - a comment that doesn't match the code should be an outright code review failure.

All the modern practices, all the principles, they're all irrelevant and pointless if you have good comments. Good comments cure all ills in a codebase.

I think the commenting part is undervalued because of the approaches like Uncle Bob's, where you hack code together until it sort of works and then tidy it up to be "nicer". That all goes against commenting becuase there's little thought gone into what you're doing. In my day the approach for coding was:

a) think about what you're trying to achieve
b) understand how you're going to achieve that
c) write the code.

In this approach, commenting works as you can even write your codebase in comments and then add the code to match them afterwards, leaving you with code documented with comments throughout. But it doesn't lend itself to hackaway coding.

code of conduct - report abuse