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

211–220 of 335 posts

Re: Clear is better than clever [pdf]

#211

Post by atq2119 »

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 }

No. This kind of alignment is basically always a mistake and hurts software maintainability in the long run.

The problem is that if one of the conditions changes, for example due to a variable renaming, you likely have to change the alignment on all lines.

Aside from being very tedious even if you're a lone coder, this creates noise in diffs that makes automatic merges fail much more frequently.

Re: Clear is better than clever [pdf]

#212

Post by datavirtue »

lovich wrote: post #138
ConcernedCoder wrote: post #131

Earlier quoted context omitted.

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.

These are both extremes and both bad. The 10 line switch statement to switch a variable is a high cognitive load for no good reason but so is a nested ternary under pretty much any circumstances, but especially with single character variables and magic numbers. >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. You're right about…

Yeah, don't nest ternaries. That's evil.

Re: Clear is better than clever [pdf]

#213

Post by [deleted] »

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…

[deleted]

Re: Clear is better than clever [pdf]

#214

Post by kazinator »

beobab wrote: post #56
illys wrote: post #55

Earlier quoted context omitted.

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

This is a beautiful way to express multiple ?: expressions.

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;

Re: Clear is better than clever [pdf]

#215

Post by atq2119 »

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

> 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? Seasoned 10x developers, titans of the industry, and all agree on simplicity and even they frequently make mistakes on easily confusable constructs such as nested ternaries (or even BS…

Yes, they all agree on simplicity. Part of the problem is that simplicity is not entirely objective.

As an extreme example, people familiar with mathematical notation have a hard time when they start using a programming language that uses '=' for assignment, because they intuitively understand it as asserting equality, which it isn't (x = x + 1 would be paradoxical). And yet we all here presumably think of assignment as something rather simple.

There are plenty of code bases where the ternary operator is used frequently. It's a more succinct (but less versatile) variant of the if/then/else expression that a number of languages have - do you find that confusing when nested?

The ternary operator is just as simple as if/then/else expressions. You may not be familiar with it, which can make it seem non-simple, but then we're just back to the observation that simplicity isn't entirely objective but subject to your background.

Re: Clear is better than clever [pdf]

#216

Post by vivekseth »

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…

Why not something as simple as `return (a - b)` ?

It’s concise and simple to understand. Instead of returning 1 or -1 it returns a positive or negative value with I think is equally effective.

Re: Clear is better than clever [pdf]

#217

Post by atq2119 »

kazinator wrote: post #214
beobab wrote: post #56

Earlier quoted context omitted.

This is a beautiful way to express multiple ?: expressions.

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;

What you're writing here is equivalent to insisting that people do:

  if (a  b) {
      return 1;
    } else {
      return 0;
    }
  }

Re: Clear is better than clever [pdf]

#218

Post by c22 »

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…

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.

Re: Clear is better than clever [pdf]

#219

Post by 5trokerac3 »

jodrellblank wrote: post #152
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…

Did you see that it was me quoting that exact quote as something to argue against ? I don't know what shorthand nomenclature of insurance underwriting is, but if it's a standard part of insurance underwriting then I would expect a new hire to be familiar with it, or need time to become familiar with it. If it's something separate like actual Gregg or Pitman shorthand English which the one underwriter used personally,…

> I would expect a new hire to be familiar with it, or need time to become familiar with it

Which equals more overhead than is necessary. Elegance over accessibility is always more expensive, no matter the product. In my experience, folks who are obsessed with "perfect" code over readable code introduce the most long-lasting, destructive bugs, because, at best, nobody wants to and, at worst, nobody can decipher their stuff.

Re: Clear is better than clever [pdf]

#220

Post by MaxBarraclough »

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…

I guess I'm in a minority here, but I wish more non-functional languages would feature pattern matching, of the sort seen in Haskell and OCaml. [0]

This language-design question is essentially a solved problem, but few new languages (outside the pure-ish functional ones) make the effort.

Trivial example in OCaml:

  let imply v = match v with 
       (true,x)  -> x
     | (false,x) -> true;;
[0] https://caml.inria.fr/pub/docs/oreilly-book/html/book-ora016...
Post reply on HN