Screw 'taste', go for obvious.
If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better.
And lack of checking on entry pissed me off too.
If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better.
And lack of checking on entry pissed me off too.
For a line of code that's going to be executed on a global scale billions of times every second, and only changed (very rarely) by extremely good developers, then I'd happily trade a bit of clarity for a bit more performance.
But if it were an oft-edited method in an in-house application that's going to be supported by junior devs? I would prefer clarity.
As always, there are no universal rules, only tradeoffs.
The next person to touch that code could be you, in two years after you've mostly moved on to another project / major upgrade and are back in a hurry to make a “quick” change, investigate a security report, deal with a scaling issue, etc
(which, for kernal code, would be turned off later, anyway)
In languages other than C, with exceptions and stack traces, most precondition checks just become clutter, anyway. Although it would be nice to have "Eiffel" style pre/post-condition (invariant assertion) blocks out-of-line that can be enabled or disabled...
But what if you're Linus Torvalds and maintaining the Linux kernel ?
The 'good taste' example may be more concise but how likely are you to spot bugs in it?
Of course that's not the full argument. And I'll throw in one more: it isn't anywhere near the top of the list in terms of importance, but aesthetically pleasing, elegant code has a certain amount of value, if only to other programmers. (Naturally, it has to be correct, too.)
Depends on what you methods are.
Pointer pointer can't be applied everywhere. If you try to reverse a linked list in O(n) time with O(1) space using a pointer pointer, the code would be less obvious than using a prev pointer.
I'm going to go sit in the corner and weep, now.
You can always go back and make it look pretty safely with good tests.
I just love code snobs that think their code is so good they don't need tests.
Yeah, but you won't. I think that's part of the reason why people care about "taste". I want to maximize the chances that essentially the first draft is good enough to be maintained for as long as possible, because years of hard-won experience has taught us that it will.
Ahh but you eventually will (at least in my experience). If you don't need to the code either doesn't matter (dead code) or works just fine.
I think I have looked at my own companies entire code base a couple of times. Do I see nasty crap... all the time. And I often fix it for good taste when it is really bad but I have to say the value prop isn't very good compared to adding tests or other automated validation (including automated profiling and dead code analysis).
Kernel code and in particular C are sort of special cases because they are hard to test and performance is generally a high concern. But for many other higher level languages and problem domains this is not the case.
I have been meaning to look how at how much code bases change overtime. In the case of Linux I wonder how much of the Kernel code has stayed the same (lets say over a 5 year period). Probably not a ton but I bet for other domains particularly business software the code either just dies or changes dramatically over time.
Then there are I suppose other domains where the code really can't physically change often (ie space probes and embedded devices).... for those systems I really really hope they have lots of tests.
As for maintenance and test code being invalid it doesn't have to be as buggy and in fact can be even in done in a data driven style or declaratively. Besides if it is a true unit test you should have written the test. If its your code and you have such good "taste" shouldn't it not "break down into a mess"?
There are plenty of projects like SQL Lite, and jQuery that have excellent "taste" not just because of the quality of code but because of the test coverage. Oh and I won't go downvote people who disagree (which my parent seems to be) because I hold that to be poor in "taste" IMO.
To the other points, "no tests" is the other extreme from "test everything." I find both views are unacceptable in practice.