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

291–300 of 335 posts

Re: Clear is better than clever [pdf]

#291

Post by [deleted] »

macspoofing wrote: post #261
naasking wrote: post #257

Earlier quoted context omitted.

> You see the problem though, I need to try it and practice it to see how simple and clear it is. You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table. > Why do I want that? To…

>It literally takes 5 seconds to understand the idiom I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. In fact, it is obviously so confusing that to make it work someone s…

[deleted]

Re: Clear is better than clever [pdf]

#292

Post by Cthulhu_ »

networkimprov wrote: post #204
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…

What we should be able to write in Go, but can't because the compiler (wrongly) imposes formatting: if a { v = 1 } else if b && c { v = 10 } else if b && !c { v = 100 } else { v = d }

I strongly disagree; creative formatting like this means that as a reader, you have to squint and readjust to this new style to see what is going on.

I mean, this whole thread reads like a holy war about code style - something the Go developers EXPLICITLY want to avoid because discussions about code style are a waste of time.

Everyone reading the above segment of code will have a different opinion on how to format it, while the real question should be "What does this code do". I mean this is highlighted in the preface of the presentation: "When you or I say that a foreign codebase is unreadable, what I think what we really mean is, I don’t understand it."

When I read this code I don't understand it, and it's not because of the formatting per se. Playing with the formatting does not make the purpose of the code clearer.

This whole thread where people argue about how to best format a structure is missing the point of the article completely.

Re: Clear is better than clever [pdf]

#293

Post by Cthulhu_ »

tomxor wrote: post #136
pier25 wrote: post #116

Earlier quoted context omitted.

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.

> We are not using parchment anymore, there is nothing to be gained by saving a couple of lines. This is not what the OP is talking about - we are not using parchment anymore, but we still have the same brains, being able to fit more code in our head with less i/o allows is a more holistic view. There is a balance in between terse and verbose that produces a reasonable length of code for what it is doing, and that is…

It really is a balance, and it's very hard to get it "just right". I mean I can appreciate a succinct oneliner (which is why I really like functional programming, doing a .map() instead of a for loop for example; it's a lot more compact without losing expressiveness, however, you do need to learn the lingo at first).

When I first went from Java to Scala, I found that while you can perform the same logic in 10 times less lines of code, each line is also 10 times as powerful and complex. A random example I found in code from back then:

    private def fetchDevices = (for (device
Super concise but at the same time the code doesn't actually do much as far as I can decode now, it's a lot of type wrangling.

Re: Clear is better than clever [pdf]

#294

Post by oblio »

pojzon wrote: post #288
brigandish wrote: post #284

Earlier quoted context omitted.

I've not heard of the supplier pattern, any chance you would direct me to a resource about it?

Im pretty sure you know what i meant, no need for nitpicking. (Does not make me any less right)

I'm not OP, but I don't know what you mean... Googling it leads me to Supplier in Java 8, which is probably not what you meant?

Re: Clear is better than clever [pdf]

#296

Post by o_pax »

c22 wrote: post #218
jimbokun wrote: post #162

Earlier quoted context omitted.

"Personally, I find that ternary example you posted to be terrible code." It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does. My nitpick would be with the language constructs themselves. The ternary operator is simply a crutch for lack of an if-then expression returning a value. if a b then 1 else 0 Or can add some white space to make the structure a little…

In Python you can write it like this: if a b: x = 1 else: x = 0 Which a lot of people seem to hate for some reason, but I always appreciated the compromise between terseness and clarity.

Python has its version of the ternary operator as well. It may look unusual due to the different order of the operands, but it works quite nicely, in my opinion:

  x = (-1 if a  b else
       0)
This emphasizes the possible values that x may be assigned to.

Re: Clear is better than clever [pdf]

#297

Post by Cthulhu_ »

ConcernedCoder wrote: post #131
pier25 wrote: post #116

Earlier quoted context omitted.

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.

I disagree, what is "saved" is your time when reading/understanding... why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish?? On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

Because if the structure is different from what you're 'used' to, you spend ten times as much time reading (or as the original presentation coins, "decoding") that one line to understand what it means.

You don't read ten lines, you decode them. If it's ten simple lines, decoding them is easy. If it's a nested ternary, it's a lot more cognitive load - unless you're used to nested ternary expressions.

However, I'd say it's a fair assertion to make that most people aren't used to reading nested ternaries.

And I think that's what Go (and this presentation) is about; you shouldn't need to get used to a certain code style to be able to decode it. You should be able to open up a file and not be surprised. If I were to come across a nested ternary, my first reaction is a raised eyebrow and a "wtf?". The wtfs / hour is one of the metrics that Go language is based on.

Re: Clear is better than clever [pdf]

#298

Post by oblio »

markrages wrote: post #193
maxxxxx wrote: post #58

Earlier quoted context omitted.

I actually prefer the long version. But I think the real trick is to be consistent in style. Parsing ternary operators is a learned skill and so is parsing long if statements. You can get used to both.

Programmers have to learn to read different styles, to read code from other projects. So use the construction that is clearest in its local context. Style is a matter of taste, just like writing English: there are synonyms and idioms for every idea that you want to express, so use that freedom to choose the clearest communication. Like English, programming code is meant to communicate to other humans, so don't artifi…

> Consistency is a hobgoblin.

A foolish consistency is the hobgoblin of little minds.

The whole quote is important. Cutting parts out changes the meaning of the whole thing.

Re: Clear is better than clever [pdf]

#299

Post by oblio »

userbinator wrote: post #279
jimbokun wrote: post #162

Earlier quoted context omitted.

"Personally, I find that ternary example you posted to be terrible code." It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does. My nitpick would be with the language constructs themselves. The ternary operator is simply a crutch for lack of an if-then expression returning a value. if a b then 1 else 0 Or can add some white space to make the structure a little…

by replacing tokens recognizable as natural language words with arbitrary punctuation It's far from "arbitrary" --- and I suspect that this dogmatic, misguided way of (not) thinking about it is responsible for the majority of the complaints and aversion, since as others have mentioned, it is completely equivalent in structure to if/else! What do I mean by "far from arbitrary"? Well... what is the character used in ba…

True, but that second part kind of falls flat when we continue your analogy.

We ask questions with ? but we don't offer alternative answer to the question with :. If anything, maybe it should be ; or even .?

Re: Clear is better than clever [pdf]

#300

Post by oblio »

whatshisface wrote: post #115
bryanrasmussen wrote: post #112

Earlier quoted context omitted.

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.

And that's why lispers are at most 1% of the total number of programmers out there, 50+ years after the language was invented.

You could say that most programmers are crap, but those crap programmers seem to make the world work, so they must be doing something right :-)

Post reply on HN