> You can always go back and make it look pretty safely with good 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.

> Yeah, but you won't. I think that's part of the reason why people care about "taste".

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.

Counterpoint: test code is also code and when unit test tyrants rule a team it can easily break down into a mess of maintenance (which suddenly more than doubles).

Speaking of good "taste" you could apply your "taste" to what are worthy tests and what are not (ie adding just maintenance). The fact of the matter is you need some sort of testing to happen or some sort of proof that your code works on a continuous basis and if you don't have that to happen IMO I'm not going to say it is good code particularly when it is based solely on one persons opinion of what is good looking code. Aesthetics compared to performance, readability and automated testing are pretty low on my list. You may say aesthetics brings those characteristics and it might but lets have some tests to prove it.

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.

I don't down vote, and in fact only recently noticed I could. I don't know who down voted you.

To the other points, "no tests" is the other extreme from "test everything." I find both views are unacceptable in practice.