[metaltyphoon]

I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.

[tasuki]

Fully agreed. No matter how "clean code", the next person or team is immediately going to label it "legacy" and complain endlessly about all the choices made by the original author(s).

[Jensson]

Many dependencies? Updating them is hell, remove dependencies and just write the utilities we need so we can update to latest easily!

Few dependencies? Too much reinventing the wheel, delete all that code and add dependencies!

There is no perfect code, can always make different trade-offs and move things around.

[tacitusarc]

My metric for clean code is how quickly a developer unfamiliar with it can understand it

[agumonkey]

It seems that anything successful, for any given era, is the one thing that minimize time to understanding better than others.

[simonblack]

Much as we denigrate COBOL, that is still its greatest advantage. Yes, it's wordy, yes it's old. Yes, it needs to be really updated. But it's still easier for a new hire to understand the COBOL old code than any other old code.

[Ygg2]

I've never had any problem digging into any Python codebase.

Even magic stuff like `@attributes` is easily searchable.

[tomphoolery]

I mean, a green field project is about as clean code as you can get. It's (reported) bug-free!