Comment by tempodox
19 hours ago
This is hallucination. Or maybe a sales pitch. If production bugs and the requirement to retain a workable code base don’t get us to write “good” code, then nothing will. And at the current state of the art, “AI” will tend to make it worse.
The first sentence is problematic:
> For decades, we’ve all known what “good code” looks like.
When relatively trivial concerns such as the ideal length of methods haven't achieved consensus, I doubt there can be any broadly accepted standard for software quality. There are plenty of metrics such as test coverage, but anyone with experience could tell you how easy it is to game those and that enforcing arbitrary standards can even cause harm.
I agree. Moreover, I submit that “good code” isn’t even a universal constant, but context-sensitive along several dimensions.
> When relatively trivial concerns such as the ideal length of methods haven't achieved consensus
Is the consensus not that there isn't one? Surely that's the only consensus to reach? I don't see how there could possibly be an "ideal length", whatever you pick it'd be much too dogmatic.
John Carmack's and Martin Fowler's coding style advice are diametrically opposed. Carmack advocates inlining complex code that is only used once. Fowler advocates extracting it with a good name to clarify intent. I'm not sure the two views can be reconciled except by noting that they address separate concerns. Carmack prioritizes visibility while Fowler prioritizes intent.
1 reply →
Yeah, test coverage isn't a replacement for good code. Worse yet, it may give you false confidence, especially if it's the AI that's writing the tests (which in practice very often is the case).
Shhhh the original poster is the CEO of an AI based company. I am sure there is no bias here. /s