Clear is better than clever [pdf]

Post by throwaway55554 » Mon, May 06, 2019, 12:23 PM UTC

Nasrudith wrote: post #26

jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern. More charitably, a better argument is…

Post by atq2119 » Mon, May 06, 2019, 12:26 PM UTC

zaphar wrote: post #24

jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

Focusing on readability of the code and putting "machine execution" second, means putting the user experience second Nothing kills a users experience like buggy code. Nothing contributes more to buggy code than unreadable or unclear code. This is why another proverb often quoted is "First make it correct, then make it fast". Fast but buggy code will lose to slower but correct code everytime.

Post by jbverschoor » Mon, May 06, 2019, 12:29 PM UTC

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

  return -1 if a  b
  return 0

Post by couchand » Mon, May 06, 2019, 12:31 PM UTC

illys wrote: post #39

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…

Post by bayindirh » Mon, May 06, 2019, 12:33 PM UTC

saagarjha wrote: post #45

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

FWIW, I write a decent amount of "clever" code (think C right out of K&R) but this took me a couple extra seconds to parse. Maybe it's an acquired skill?