“Clean code” isn't actually clean

I don't understand the negativity in the top voted comments here! It's almost as though I read a completely different article than the one being commented on.

The comments here are being dismissive and then reiterating what the post said! Here's the summary from the post :

> So I stopped worrying about whether my code is perfect. And I just accepted that if I can't see any immediate flaws with the code, and if all the tests pass (whether automated or manual), then it's fine. And I trusted that if I ever come across a bug, I can fix it.

Why, specifically, is that a bad thing?

Exactly, even if you don't write tests for a component, it pays off to think about how it could be made testable. You can still choose to add tests later on.

> A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant.

Sometimes, your new paradigm is actually something that they tried 10 years ago.

> In the end, you can sum up all rules into one: Make it easy to maintain

That is only one of the many facets of programming that you have to balance: performance, memory consumption, ... .

If you want to push your system performance to the extreme, believe me, "easy to maintain" is not going to happen. But that is the trade-off that you will have to make at that point.

Veterans know that everything is a trade-off.

Let me give you one extreme: you are writing a throw away prototype. How much time and effort are you going to spend (=waste) on making your code easy to maintain?

I'll give you my veteran answer:

- If you are in 100% control of the project, you know you will throw away the prototype, and you can throw things quickly together.

- If you have a manager, he will take 1 look at the prototype and say "Wow, it's almost complete! Don't start a new project, just add these features to your prototype and it's done.". So in that case, make the "throw away prototype" easy to maintain.

That is what veterans bring to the table: making trade-offs in specific situations. And they've been through a lot of situations.

I think the short functions thing is a funny one. The benefits of short functions are definitely praised in the book, but they are really more of a side effect of the real goal: to have pieces of logic that do one single thing that can be summed up in a function name and understood as a clear input -> output 'step' at the level of abstraction above, without having to dig in to find out 'how it works' or understand any weird quirks / unexpected side effects etc.

Usually, by their nature, such functions don't end up being very long. This is great, but it remains just a nice side effect of the real goal, and one that is not more important than the real goal. To artificially break up a slightly longer function which is very focused in its behaviour, just for the sake of line count, is probably a mistake.

To be honest, I can't remember how clearly the book makes this distinction, or if it does at all, but I feel like it probably could be made clearer given how common this misinterpretation is.

I'm 33, and while I don't think I'm "at the top of my field", I have experienced quite a bit and am confident that I can both produce and identify high-quality code.

In my mind, the biggest change as I've grown in my career is that I've gone from judging code quality to judging code suitability.

For example - the application I'm working on right now, there is is a javascript file that initializes complex data tables using the jQuery DataTables plugin. It's several hundred lines of redundant code, with several functions that actually do the initialization differently depending on the classes that are applied to the table element. It is unquestionably "low quality" code, but I have no intention of attempting to refactor it. Why? Because there are customers whose UIs are dependent upon the bugs and undocumented assumptions that are baked into that code, and refactoring it would break things from their perspective. If I did that, by the time I dealt with all the bug reports and feature requests from customers, the nice clean code that I'd written would look like the code I have now. Instead, I've written a new JavaScript file to initialize data tables going forward, and all new instances use that. They are slightly visually distinct from the "old-style" versions so users know to expect the slightly different (but now consistent) behavior. I'm very resistant to adding features to the legacy code, and instead, offer to "convert" the legacy tables to the new layout one-by-one when a new feature is requested. Eventually, we may reach a point where we can retire the legacy code - but in all likelihood, that code will be there longer than I will work here. This approach of "walling off" code that has become unwieldy and difficult to modify is one of the things that I look for when determining where a developer is in their career.

> You need to keep a project clean. This means profound refactors when concepts for the product change.

If the purpose of a company were to produce the most excellent software possible, I'd agree with you, but the purpose of a company is to make a profit. If you do a "profound refactor" every time requirements significantly change you're likely to never launch a product at all, much less iterate quickly enough to build a profitable product. You have to learn to deal with cruft and manage its lifecycle, not try futilely to prevent it from ever occurring. Part of that is learning to break things down into discrete components and limit interdependencies so you can refactor each component in isolation, but another part is learning to segregate cruft that has accumulated and keep shipping without creating a mess that slows down how quickly you can iterate in the future.

> It takes effort to maintain a clean project, many will try to say "it's not worth it".

"Worth it" doesn't necessarily mean "worth it from the perspective of the developer". It can also mean "doing this right is going to take longer, and in order to meet our business goals we can't take the time". As long as the long-term impact of these decisions are passed on to the decision-makers on the business side, there are absolutely times when "it's not worth it" to write clean code.

> That's just out of the question, it's your job, it doesn't have to be always pleasant or easy.

Nope. Your job as a developer is to provide more business value than you consume. If you're getting paid $100k you must provide more than $100k of value or you will eventually be out a job, regardless of how clean your code is.