Live data from Hacker News

Clear is better than clever [pdf]

dave.cheney.net

81–90 of 335 posts

Re: Clear is better than clever [pdf]

#81
post #61
post #39

Earlier quoted context omitted.

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…

> Combinations of if/else can seriously damage readability and maintainability. Yes, that's why for selections we usually use switch/case. But of course every programmer worth his money just knows that ?: is right associative and that '&&' is on precedence level 11 while '?:' is on 13. If that's not "clever code", I don't know what is...

Never thought the ternary operator required high expertise for associativity/precedence reasons and could sentence me to "clever code"...

Besides switch/case do not apply to a mix of true/false conditions but to the different values of a single variable.

Funny :-) Thanks.

Re: Clear is better than clever [pdf]

#83

Earlier quoted context omitted.

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…

>... 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. No, it doesn't suggest this at all. It means use the merge sort but implement it in a clean, understandable way.

It means use the merge sort but implement it in a clean, understandable way.

https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort - which ones of these do you consider objectively "clean and understandable"?

Why should any of them (Prolog, Mercury, J, Common-Lisp, etc) be considered "not understandable" instead of "not familiar to the reader"?

Re: Clear is better than clever [pdf]

#84
post #39

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…

I much prefer the if/else, thanks very much.

Re: Clear is better than clever [pdf]

#85

Earlier quoted context omitted.

I’d say it’s in fact where the real fun happens

Working on personal projects, not having to conform to other people’s requirements, trying a bunch of cool hacks and getting to see how things really work…that’s the most fun part of programming!

I've never been happier working on a project than when I'm working with somebody that is a better programmer than me and willing to give advice and criticism.

Re: Clear is better than clever [pdf]

#86
post #79

Earlier quoted context omitted.

I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

I wouldn't call that example nested; I'd call it sequentially chained, and I think that pattern is quite clear even with many conditions in the sequence. That pattern is the expression equivalent of if..; elsif..; elsif..; elsif... Writing it out in long form using actual if statements doesn't add much clarity, and costs in verbosity, as the OP says, macro-clarity versus micro-clarity. I agree with the sibling to thi…

This is a natural point of disagreement. The question is what you're trying to do.

Is this the lowest level of decision making in something like a large drawing application, or some CAD or financial package, then for the love of God, take the concise approach ! If you consistently take the longer approach, may God provide mercy on your soul (and a very large monitor) when you get to vector multiplication or matrix math.

If you're writing 3 business rules in something that's important and needs reliability and therefore should not have complexity ? Then it might be better to write it out.

(in both cases, because of the potential for stupid mistakes, I'd add tests)

But there's no single solution for all situations. High complexity software ? Concise will help out more. Low complexity software ? Write it out for clarity.

Re: Clear is better than clever [pdf]

#87

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…

I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

They are confusing and misleading to anyone new to your code base.

But why should that be the main thing to be concerned about and prioritise? In what way are they "misleading"? Is it really the state of the industry where a new person cannot learn a codebase, has no time or effort, and cannot read a single line of the language they were hired to work on, and that's the person we should build everything for?

Does it work like that in any other industry?

Re: Clear is better than clever [pdf]

#88
I agree with the sentiment, but not with Go's interpretation. To me, higher-order functions like map and reduce are much easier to read than the equivalent for loops and are less likely to have subtle bugs (off-by-one errors, etc.) because they more directly capture the author's intent.

Re: Clear is better than clever [pdf]

#89

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…

I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

This I think is obviously personal preference, but to me nested ternarys are pretty readable as long as they're wrapped and indented.

When they are, you basically get something that looks visually like a decision tree. This can read really nicely in situations where declarative style code fits better - for example embedding nested ternarys in JSX is quite a popular pattern for this reason.

The caveat is, you have to be 'used to' reading the ? and : symbols and instantly mapping them to if/else, but I certainly don't think getting used to this in a short time frame is beyond expectation for someone who's not already, i.e. new team members etc.

Re: Clear is better than clever [pdf]

#90

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…

I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

If someone is hired to work on your code base, presumably they know the language. They know ternarys work...

If they don't then they need to learn.

You can't say don't use specific language features because some devs can't be bothered to learn them.

Post reply on HN