I agree with the condition about "If you're at BigCo". It really depends on who's going to read/edit the code, how often, and how many times it's going to be executed.

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.

If you understand C pointers, this is obvious: it keeps track of where the pointer to the current node came from, and replaces it with a pointer to the next node once it reaches the entry to be removed.

I agree, in fact taste might rightfully be defined as that which is obvious to an experienced developer in the environment. Code which simply relies on conventions and avoids complexity is often immediately elegant.

This is a great point but I'm trying not to think disparagingly about the skill level future maintainers, too: deadlines and distraction are a powerful negative equalizer.

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

For heaven's sake, everyone, please stop getting hung up on the fact that there's no error checking. Example code usually doesn't show error checking because it obscures the main point of the example.

Not shown: assertions :-)

(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...

SPARK does that with efficient, system code. Then proves the code free of common errors in C. Then other tools can generate unit tests from the specs just in case. Frama-C does something similar for C. I'm not sure what the usability or thoroughness is like vs SPARK, though.

http://www.spark-2014.org/about

Totally agree, never play code golf with your production code. Your cleverness will bite you in the arse when you can't be promoted or allowed to move to a new project, because your code is so clever that you're the only one who can properly maintain it.

>If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better.

But what if you're Linus Torvalds and maintaining the Linux kernel ?

Obvious is still important. Even kernel developers make mistakes.

The 'good taste' example may be more concise but how likely are you to spot bugs in it?

But I think that's part of the argument. Reasoning about edge cases in code full of nested loops and conditionals is hard. Eliminating branches and opportunities to hide fencepost errors (for instance) goes some way towards reducing cognitive noise so you can focus on the meat.

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.)

More likely, because there are fewer code paths to follow. Given Linus's explanation, I think that's part of the basis of his "taste", not conciseness (which in this example I suspect is a byproduct).

> how likely are you to spot bugs in it?

Depends on what you methods are.

Define obvious. At least the pointer pointer version is obvious to me in this task.

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.

Not sayin' you're wrong, but...

I'm going to go sit in the corner and weep, now.

I say screw 'taste' and 'obvious' and instead go for it has high coverage unit tests and lots of them.

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.

> 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.