[cogman10]

IMO, none of the things OP listed here are what makes code "good". Test coverage, documentation, organization, constant style, "best practices". You can have one or all of those aspects in any project and it can still be a nightmare to maintain.

What makes code good is "How hard is it to fix issues" and "How easy is it to understand". You can have well documented code which ultimately is hard to understand. You can have well organized code which ultimately makes fixing issues with said code hard.

In order to know if a code base is good, you have to experience maintaining it. You can't (easily) know a code base is bad with cursory glances to mental checkboxes about it.

The metric I use for good code now a days is "How often does this wake me up in the middle of the night?" Good code is code that doesn't cause my employer to pester me off hours.

[jrochkind1]

I would say "simple changes are simple to make" is pretty much the whole goal of software design/architecture... and is actually really hard, you don't know for sure if you've hit it until you try, and is still a craft you get better at only by experience (especially including domain experience) not by following "best practices" or "design patterns".

[cogman10]

> and is actually really hard, you don't know for sure if you've hit it until you try, and is still a craft you get better at only by experience

Totally agree. Part of what makes it so difficult is design isn't a one size fits all thing. The valuable part of experience is knowing when to and when not to apply a design pattern or "best practice".

[jollyllama]

Hmm, I'd say test coverage is a good metric, to a degree. "No tests" is a code smell! It results in hard to fix issues because the code is often poorly organized and it absolutely makes it hard to fix issues because you can't tell if you've made a regression, as there are no tests.

[cogman10]

I've been in more than a few places where tests were a net negative to the project. A poorly written tests can be worse than no tests at all.

Probably the most frustrated I've been in a code change is when a single line resulted in 10+ test files being updated (adding a parameter to a method call used in one place in the code...) This provided no actual benefit to the project at as a whole and was mostly just code churn.

What's worse, I've also seen places where there are a bunch of extra code paths added to support tests! In other words, code was made MORE complex simply to support tests. That's getting the cart before the horse.

Not to mention the times I've had to dedicate a significant part of my time fixing tests for a project because they intermittently fail (hurray for `Thread.sleep` in a test...) I wasn't going to work on the project when it would randomly fail unrelated to the code I wrote.

All this is to say like my original comment, there's no one metric you can look at and say "yeah, this is good code".

[jollyllama]

Absolutely. I've also seen dogmatic devotion to testing that results in what you describe.