Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clear is better than clever [pdf]

dave.cheney.net

Post reply on HN
Print view View original

91–100 of 335 posts

Re: Clear is better than clever [pdf]

#91

Post by coldtea »

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…

>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 nowhere near clear. I frequently use a single level ternary, but this is an abomination and very easy to make a subtle error in.

Re: Clear is better than clever [pdf]

#92

Post by Random_Person »

davnicwil wrote: post #89
Random_Person wrote: post #70

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.

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…

Writing for yourself is a fallacy. We can all read our own code. Write for the next guy who has to look at it and figure out what is going on.

Re: Clear is better than clever [pdf]

#93

Post by maxxxxx »

LandR wrote: post #90
Random_Person wrote: post #70

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.

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.

I know ternary operators very well but I still have to think twice when I see them nested

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

Would you say the same about C++? In my view it’s a good practice to use only a subset of a language consistently and not use all features. I have seen JavaScript code where I had to do research for half an hour before I could figure out what it really meant.

Re: Clear is better than clever [pdf]

#94

Post by Random_Person »

jodrellblank wrote: post #87
Random_Person wrote: post #70

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.

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…

Because you can already read your own code. Writing for yourself is bad code. Write for the next person that has to figure it out.

Re: Clear is better than clever [pdf]

#95

Post by 5trokerac3 »

jodrellblank wrote: post #87
Random_Person wrote: post #70

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.

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…

> Does it work like that in any other industry?

Yes, it does. Imagine you were a new underwriter at an insurance company and your predecessor used the shorthand nomenclature for every detail on the accounts you're taking over, and failed to write out any of the detailed reasoning behind why they chose to approve or deny claims. How much longer would it take for you to be able to fill their shoes than if they had been just a little bit more descriptive in their documents?

> "Programs must be written for people to read, and only incidentally for machines to execute." - Harold Abelson

Re: Clear is better than clever [pdf]

#96

Post by coldtea »

LandR wrote: post #90
Random_Person wrote: post #70

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.

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.

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

It's not whether some constructs are parts of the language (languages can have any crap in), it's whether some constructs are bad, confusing, and should be avoided (whether you know what they do or not).

Re: Clear is better than clever [pdf]

#97

Post by vladus2000 »

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…

I completely agree. At my first professional programming job, I had to follow a style guide that forced me to code the verbose way. It drove me nuts and I found another job about 6 months later.

The less lines of code, the faster you can read a code base, apply fixes and have less bugs. Obviously you can take that too far and make code so dense no one can read it. It is finding a balance between the two. Comments can go a long way towards making complex code understandable within reason.

Re: Clear is better than clever [pdf]

#98

Post by java-man »

coldtea wrote: post #91
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…

> 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 nowhere near clear. I frequently use a single level ternary, but this is an abomination and very easy to make a subtle error in.

also, try to step through this in a debugger.

Re: Clear is better than clever [pdf]

#99

Post by 5trokerac3 »

hotBacteria wrote: post #65
illys wrote: 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…

You can write it without resorting to one-line conditionals: if(cond1){ myVar = 1; } else if(cond2 && cond3){ myVar = 10; } else if(cond2 && !cond3){ myVar = 100; } else { myVar = 4; } But when I encounter this kind of situations I have other problems than code formatting anyway: with 3 conditions you have 2^3 possibilities to check: are you really really sure (!cond1 && !cond2 && cond3) should give you defaultValue…

If you're running through that many conditionals, it may be clearer to work them into a state enum that you can use with a switch.

Re: Clear is better than clever [pdf]

#100

Post by davnicwil »

Random_Person wrote: post #92
davnicwil wrote: post #89

Earlier quoted context omitted.

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…

Writing for yourself is a fallacy. We can all read our own code. Write for the next guy who has to look at it and figure out what is going on.

I completely agree with you :-)

But as I say above, I think in certain situations they can be more readable for everyone.

Post reply on HN