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

111–120 of 335 posts

Re: Clear is better than clever [pdf]

#111

Post by mannykannot »

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…

While code of this size and scope can be unclear, it is not where the real problem lies. In general, what's not clear is some version of "what does this do" and "why is this being done" where "this" is often a function call with an arbitrary amount of complexity behind it.

When the code is mostly calls to well-documented APIs, clarity is achievable (though not guaranteed.) if it is more complicated than that, I do not know that there is any way to achieve clarity other than to structure it, internally, in that style.

Re: Clear is better than clever [pdf]

#112

Post by bryanrasmussen »

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.

how many branches/how much depth in a ternary statement would you consider to be too many/too much?

Is there never going to be any level of depth in a ternary statement which you will think is perhaps too great, and want to switch to some more verbose syntax?

Re: Clear is better than clever [pdf]

#113

Post by verall »

macspoofing wrote: post #60
illys wrote: post #55

Earlier quoted context omitted.

Maybe you'll prefer return (a b) ? 1 : // a greater 0; // equal

What's the point? Why not just make it an if-elseif-else block and make it obvious?

Ternary isn't the same as a branch and you want your this simple comparison function to get inlined every time

Re: Clear is better than clever [pdf]

#114

Post by bryanrasmussen »

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…

I once had to maintain a chat app in which the first developer had written something like the following at some point:

if (statement = ref) { print(statement) } else { print('have you done everything right?') }

was I wrong to be confused as to what he might have intended with statement = ref? Because he was in fact using the language functionalities to express what he wanted. I just thought it looked confusing and misleading.

Re: Clear is better than clever [pdf]

#115

Post by whatshisface »

bryanrasmussen wrote: post #112
LandR wrote: post #90

Earlier quoted context omitted.

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.

how many branches/how much depth in a ternary statement would you consider to be too many/too much? Is there never going to be any level of depth in a ternary statement which you will think is perhaps too great, and want to switch to some more verbose syntax?

A lisper would say that there is absolutely no limit, and that in fact all programs should be structured like that.

Re: Clear is better than clever [pdf]

#116

Post by pier25 »

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…

As long as verbosity is meant to make your code more explicit I'm fine with it.

Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

Re: Clear is better than clever [pdf]

#117

Post by pier25 »

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.

The problem is not knowing how ternaries work, it's about how explicit is that line of code.

Re: Clear is better than clever [pdf]

#118

Post by jaabe »

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…

Is your code really clear though? What are a and b? What types are they? What if they, or one of them aren’t that type? Why would you call the function? When would you call it?

I mean, I get that your example is directly related to the point you are making in verbosity, I don’t even necessarily disagree with you, but your example isn’t very clear to me.

Re: Clear is better than clever [pdf]

#119

Post by demo123 »

_bxg1 wrote: post #78
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.

I would make the exception that if you judiciously indent then across multiple lines, to reflect the nested structure the way the if/else equivalent would, then they're fine. But yeah, nested ternaries on one line are impossible to follow.

If you even need to indent them then why you don't write a full if else statement instead? Nested ternaries shouldn't be used at all.

Re: Clear is better than clever [pdf]

#120

Post by piaste »

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.

> We can all read our own code

Six-months-ago-myself thought so as well. Turns out six-months-ago-myself is a goddamn moron.

Post reply on HN