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

301–310 of 335 posts

Re: Clear is better than clever [pdf]

#301

Post by loup-vaillant »

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…

Nitpick: I often break nested conditionals in several lines, like this:

  return a  b ?  1
      :           0;
Reads like a switch statement, yet not overly verbose. I can parse it even more easily than the one liner.

Your point about "macro-readability" is spot on though. Nobody should care about the readability of an isolated piece of code. We should care about the readability of pieces of functionality and that generally requires understanding of a whole function, or even a whole class/module.

Re: Clear is better than clever [pdf]

#302

Post by sametmax »

__s wrote: post #270
sametmax wrote: post #57

Earlier quoted context omitted.

No, what Python suggests is just returning the value you sort on, or a tuple of the values to sort on. cmp() is deprecated because there is seldom reason to use it anymore. E.G: Sorting words according to their number of letter is just: sorted(words, key=len) You don't return 1, -1 or 0. If you want to rank participants of a game in a dictionary of scores using names as keys and points as values, you would to: sorted…

Official docs: https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa... > If you really need the cmp() functionality, you could use the expression (a > b) - (a < b) as the equivalent for cmp(a, b)

αν

Re: Clear is better than clever [pdf]

#303

Post by Cthulhu_ »

pier25 wrote: post #117
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.

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

Exactly; to use the phrasing used in the presentation, it's about how difficult it is to decode the statements. I'm not a C guy; a regular ternary is fine, as long as it's simple enough. A nested ternary? That gives me all kinds of red flags because I have to lean in and frown and go over it a few times to decode it.

Re: Clear is better than clever [pdf]

#304

Post by Cthulhu_ »

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…

Yes. Go is intended for BIG codebases - millions of lines of code. You can't afford to have to squint and decypher one particular author's code style when you have to go through that amount of code.

It's much easier to go through a codebase if everyone uses the same code style and you get the least amount of surprises. This does however require you to give up your own ego, that is, you have to conform to the standard.

Re: Clear is better than clever [pdf]

#305

Post by Cthulhu_ »

userbinator wrote: post #282
5trokerac3 wrote: post #95

Earlier quoted context omitted.

> 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…

No, it doesn't. In most other industries, you are simply considered incompetent if you don't possess the skills or aren't willing to learn the ways of the trade. Look at aviation for example: pilots and ATC talk in jargon, acronyms, and abbreviations like it's a completely different dialect of English, anyone who complains that they can't understand would be laughed at and told to keep learning, and that's the way it…

> Look at aviation for example: pilots and ATC talk in jargon, acronyms, and abbreviations like it's a completely different dialect of English, anyone who complains that they can't understand would be laughed at and told to keep learning, and that's the way it should be.

Yes, but the jargon and language used is standardized; pilots don't get to put their own twist on e.g. formal communication with the tower when they come in to landing. You don't get to switch to idk, km/h when communicating your airspeed.

Re: Clear is better than clever [pdf]

#306

Post by psychoslave »

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…

  enum situation { boring, clear, cleaver }
  
  selector(context)
    if context.proves(cond1)
      return cleaver
    if context.proves(cond2)
      return clear
    return boring

  adjudicator(context)
    switch( selector(context) )
      cleaver: make_something_cleaver()
      clear: make_something_clear()
      default: make_something_stupid_simple()
Not completely the same situation, though, as there are no assignation here. For simple cases (`v = e0 ? e1 : e2`), ternary operator sure is fine, but for more complex cases, `some_var = selector(context)` tend to be a clearer path. That will also be better rendered in your API as the function fine documentation will have more chance to be extracted properly.

Re: Clear is better than clever [pdf]

#307

Post by anbop »

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…

One could make analogues to prose writing. The author's is in the style of xkcd's "Thing Explainer" where they deliberately only use 1000 words: https://xkcd.com/1133/

Yours is in the style of James Joyce where it's very dense...

the easiest to read is probably somewhere in between

Re: Clear is better than clever [pdf]

#308

Post by Retric »

loup-vaillant wrote: post #301
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…

Nitpick: I often break nested conditionals in several lines, like this: return a b ? 1 : 0; Reads like a switch statement, yet not overly verbose. I can parse it even more easily than the one liner. Your point about "macro-readability" is spot on though. Nobody should care about the readability of an isolated piece of code. We should care about the readability of pieces of functionality and that generally requires un…

Using semantically meaningless structure is unlikely to survive being edited.

  if (a
Is simple boring code, has the advantage of looking odd when something odd happens.

Re: Clear is better than clever [pdf]

#309

Post by GorgeRonde »

Cthulhu_ wrote: post #292
networkimprov wrote: post #204

Earlier quoted context omitted.

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…

> When I read this code I don't understand it

?

Re: Clear is better than clever [pdf]

#310

Post by rishav_sharan »

jimbokun wrote: post #162
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.

"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…

> It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does.

Thats very subjective. As a beginner dev, the ternary series is almost un-understandable for me. While the if/else blocks are far easier to glance at and digest.

Post reply on HN