Post #2675564

2026-04-22 14:22 UTC

Code coverage has been taken as a measure of code quality, whether code is a good, at least in a specific dimension. In some senses, it functions to answer if code good. But usually by its absence as indicator rather than its presence as a predictor. That is to say, I can get 100% code coverage on buggy code and 0% code coverage on well performing code. It's not common, but it is possible. So I return to the question: can code be objectively good? idk, that's why I'm asking you all here. 2/

Replies (2)

@jelte@mastodon.nl 2026-04-22 14:31

@raiderrobert@mastodon.social i see tests and their coverage more of a way to check for soundness and completeness, and not so much as a measure of quality itself. There's also efficiency and subsidiarity (if that's the term; does it not do things outside its stated goals) to consider, i reckon

Open ##2675565
@BoydStephenSmithJr@hachyderm.io 2026-04-22 15:17

@raiderrobert@mastodon.social What is "good", objectively? I think the utilitarian view of good is as close as we get to an objective good, but that's entirely based on the (subjective) experiences of conscious beings. In that case, I think there are a lot of flawed code that is still objectively good. Things like functional pearls or even just really good bug examples can inspire and enhance the reader. There are many objective measures and falsifiable properties that can be applied to code. If you define "good" to be some combination of those measures and properties, then you can do science to determine if some code is good. But, it is useful to remember Goodhart's Law (https://en.wikipedia.org/wiki/Goodhart's_law) when engaging is this practice, whether code or something else is the thing being tested for "good"ness. Finally, code can be part of a system that is good (in either of the previous senses), even if the code in isolation doesn't satisfy either of those criteria. If the code is essential to that system, then I feel it should be considered good. As far as metrics, I think coverage based on mutation testing, is a nice one. At 100% you basically know every control flow operator in your main code is essential and your tests contain properties about each path. But, even that is just one aspect/metric; I certainly wouldn't claim this metric is _the_ one that divides "good" code from not "good" code.

Open ##2675567