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

281–290 of 335 posts

Re: Clear is better than clever [pdf]

#281

Post by olah_1 »

Chris_Newton wrote: post #258
Consultant32452 wrote: post #199

Earlier quoted context omitted.

That's interesting. I wonder if that's influenced by the languages we use, as they might have different cultures. I primarily work in Java, which is famously verbose.

Reading this discussion, I think one inescapable conclusion is that personal experience has a great influence on what people consider a desirable coding style. Among other things, people often infer something that isn’t actually there, because such an inference would hold in the programming language(s) or the more general programming model(s) they are familiar with. For example, there’s a big thread about the three-w…

I think the semantics of the language is also important.

A ternary operator in a C like language probably is frustrating because it's some magic that was just shoehorned into the language with no rhyme or reason behind it.

However, in a language like Perl 6, each magical operator has an intelligible semantic meaning behind it almost like a natural language. So when you mix and combine different operators, it starts to make sense to you. See this post for an example https://perl6advent.wordpress.com/2017/12/11/all-the-stars-o...

Re: Clear is better than clever [pdf]

#282

Post by userbinator »

5trokerac3 wrote: post #95
jodrellblank wrote: post #87

Earlier quoted context omitted.

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…

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 should be.

Yet the software industry seems to have developed an illness of perception, that encourages the continual lowest-common-denominator dumbing-down of code and an aversion to learning. From what I've seen "collaboration" as a justification for this, and from the types of people who are proponents of it, it appears to be related to the effort of managers to attempt to turn developers into disposable and easily replaceable drones; something which everyone actually writing code should be against. In the trades, there's no lack of teamwork either, but the prevailing notion is "the least skilled/experienced learns from the most" --- only in software does there seem to be a strong counter-trend to that. Perhaps we should not encourage the degradation of our craft.

Maybe that quote should be modified slightly too: "Programs must be written for suitably qualified people to read"

Re: Clear is better than clever [pdf]

#283

Post by a1369209993 »

c3534l wrote: post #230
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…

The fact that half the people in this subthread think that your version is less readable and half think it's more is really strange to me. If you have to traverse more lines and scroll down and switch between lines to track variables and conditions, that's unpleasant to parse. On the otherhand, excessively dense code where you have to figure out which of multiple function calls or syntax constructions to start at, th…

I think part of the problem is that it'sn't visually obvious that ? and especially : are lower precedence than . I suspect that most of the people with genuine objections would feel better about:

  ab ? +1 : 0
  # or maybe
  a  b ?? +1 !! 0  # perl6 style
  # or
  a  b then +1 else 0
not for verbosity vs succinctness but for the mnemonic that visually-smaller operators bind more tightly.

Re: Clear is better than clever [pdf]

#284

Post by brigandish »

pojzon wrote: post #241
hotBacteria wrote: post #65

Earlier quoted context omitted.

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…

I think its a poor example. How often you are going to write something like that in RL scenario? In case of more complex data generation you could use supplier pattern and combine it with strategy. No need for any if else statements at all. Sure it requires a lot more of work but is future proof and clear.

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

Re: Clear is better than clever [pdf]

#285

Post by userbinator »

Theodores wrote: post #184
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…

Compilers are very good at doing the ternaries for you. With good ol' Javascript you get things like the Google Closure Compiler that will return yet more Javascript rather than some bytecode, this informs me that my use of ternaries is a waste of time. I might as well go for the if/then/else type of approach and refactor it when it gets ugly into some functions. My excuse for taking this approach in all languages is…

The example ternary would require me to stop and think for a moment, if it was in boring if statements I could explain it to a not-so-technical person in terms they could understand, even if they could not write it themselves.

On the contrary, even a "not-so-technical person" is likely to be able to guess at the meaning of a question mark; and as a bonus, it's not specific to English either.

Re: Clear is better than clever [pdf]

#286

Post by kazinator »

naasking wrote: post #259
kazinator wrote: post #214

Earlier quoted context omitted.

I don't agree. It occludes the nested structure. We can regard the condition as the head of a clause, and the ? and : as heads of sub-clauses: A ? B : C which leads to: return a b ? 1 : 0;

> It occludes the nested structure. The nesting is irrelevant to understanding the semantics, so this objection doesn't fly. The idiom is basically just a truth table with conditions on the left and the matching value on the right. You read it left-to-right, top-to-bottom, just like all other code. The first condition on the left that matches returns the value on right-hand side.

> The nesting is irrelevant to understanding the semantics

The nesting is absolutely relevant to producing the semantics.

The following uses deceptive whitespace to suggest a nesting that is contrary to the actual nesting, interfering with understanding:

  if (foo)
    if (bar)
      xyzzy();
  else
    flop();
The ternary operator A ? B : C is the goofy invention of demented mind. In nested situations, it is mind-bendingly unreadable. It behooves us to style it in a way that reveals the abstract syntax tree structure.

In C, I would in fact recommend:

  #define if3(a, b, c) ((a) ? (c) : (c))

  return if3(a  b, 1, 0));
Now we can have it in one line, yet it's clear.

Re: Clear is better than clever [pdf]

#288

Post by pojzon »

brigandish wrote: post #284
pojzon wrote: post #241

Earlier quoted context omitted.

I think its a poor example. How often you are going to write something like that in RL scenario? In case of more complex data generation you could use supplier pattern and combine it with strategy. No need for any if else statements at all. Sure it requires a lot more of work but is future proof and clear.

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)

Re: Clear is better than clever [pdf]

#289

Post by stevesimmons »

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)

Just maybe he genuinely doesn't know what you mean. I mainly use Python and have no idea what you are talking about.

(You might consider reflecting on your tone and message. It presupposes bad faith on the other party, is dismissive and condescending, and you are probably less right than you think you are.)

Re: Clear is better than clever [pdf]

#290

Post by brankoB »

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, too, have no idea what a supplier pattern is. Don't think that's a very mainstream notion.
Post reply on HN