4 ms·

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

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.

Sir_Substance 10y ago
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.
- deleted 10y ago
  [deleted]
acdha 10y ago
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
blowski 10y ago
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.
agentgt 10y ago
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.
- deong 10y ago
  > 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.
  - agentgt 10y ago
    > 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.
- sidlls 10y ago
  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).
palunon 10y ago
>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 ?
- IshKebab 10y ago
  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?
  - __jal 10y ago
    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.)
  - colanderman 10y ago
    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).
  - Chris2048 10y ago
    > how likely are you to spot bugs in it? Depends on what you methods are.
makomk 10y ago
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.
- thegenius2000 10y ago
  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.
jsli 10y ago
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.
RandomOpinion 10y ago
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.
- Roboprog 10y ago
  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...
  - nickpsecurity 10y ago
    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 http://www.spark-2014.org/about
Roboprog 10y ago
Not sayin' you're wrong, but... I'm going to go sit in the corner and weep, now.

Sir_Substance 10y ago

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.

deleted 10y ago
[deleted]

acdha 10y ago

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

blowski 10y ago

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.

agentgt 10y ago

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.

deong 10y ago
> 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.
- agentgt 10y ago
  > 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.
sidlls 10y ago
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).

palunon 10y ago

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

IshKebab 10y ago
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?
- __jal 10y ago
  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.)
- colanderman 10y ago
  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).
- Chris2048 10y ago
  > how likely are you to spot bugs in it? Depends on what you methods are.

makomk 10y ago

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.

thegenius2000 10y ago
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.

jsli 10y ago

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.

RandomOpinion 10y ago

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.

Roboprog 10y ago
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...
- nickpsecurity 10y ago
  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 http://www.spark-2014.org/about

Roboprog 10y ago

Not sayin' you're wrong, but... I'm going to go sit in the corner and weep, now.