Hacker News Reader

Comment by ufmace | Hacker News Reader

I haven't made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it's a perfectly valid things to do, provided that it isn't used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever, or copy-pasting the same code in 20 places because they don't understand functions and classes.

View on HN

I'd like to hear others' opinions: There's a guy at my work who loves to use doubly, triply, quadruple-ly nested ternary operators. I always find them super hard to read. Am I just a dunce, or do I have a point in thinking it's unnecessarily terse.

Ternary operators can be fine. Nested ternary operators are hardly ever a good idea.

One thing that people writing this sort of code seem to miss is that it's not just about expressing the code as concisely as possible - other people including oneself in future need to be able to read it easily.

What I would recommend in a code review for anyone using nested ternary operators is just to break them up using meaningful variable names so that you have one ternary operator per statement. It'll be easier to read and the names will help understand what's going on more easily.

Nested ternary operators are hardly ever a good idea.

Would using ternary operators as a terser switch statement be fine?

  int a =
    b == 1 ? 2 :
    b == 2 ? 3 :
    b == 3 ? 5 :
    -1;

I like those, but they do need to be properly formatted and only "tail-nested".

I also tend to format them thus:

    int a = b == 1 ? 2
          : b == 2 ? 3
          : b == 3 ? 5
          : -1;

Feels much more "case analysis-y" and clearer.

Still, a language having proper support for expressive conditionals is probably better.

Also the way Python's ternary was defined means it should never ever be nested, it looks nasty.

Format them like you would if-else, then they're easy to read:

    x = y ? 1
          : 2;

I'd encourage your coworker to use a language where if/else is an expression and not a statement. :) Of the languages mentioned in the article, Rust, Haskell, Scala, and OCaml all have this as the only form of if/else: you can write something like x = if foo then bar else baz, so you can nest them with some parentheses for readability. Python's if/else is a statement, but it has a slightly different syntax for the if/else as an expression - bar if foo else baz - which is a little less readable but still workable.

It's only the Algol-syntax-family languages (C, C++, Java, JavaScript, etc.) that have the inscrutable ternary operator and if/else as a statement.

Algol family syntax is not the same as C syntax. Algol 60 has if-then-else as an expression like "x := if foo then bar else baz". In Algol 68, an ENCLOSED-clause like if-then-else-fi is a PRIMARY, so it can be used anywhere other primaries like identifiers and denotations (literal constants) can be used. "Begin" and "end" are synonyms for ( and ). Both languages are defined on the level of symbols instead of bytes or characters. These symbols can have multiple representations including punctuation and text in non-English languages like Russian. A lot of people today don't know what Algol family syntax looks like which is a real shame because they're very clean and elegant languages.

I prefer less terse code for readability too. LOC is a decent approximation for complexity but it breaks down when people optimize for it.

It's a tricky problem to decide which idioms are most expressive/readable/maintainable as it's has a group dynamic. My rule of thumb, if I feel I've written clever code it's time to rethink approach.

Usually it's awful. I wish JavaScript had if else expressions. Sometimes it can help to break up the lines with indents if you need a single expression:

  var myvar = foo < bar
    ? bar
    : bar < baz
      ? baz
      : 0

I settled on this a while ago which I think is perfectly readable:

    const myvar
      = foo < bar ? bar
      : bar < baz ? baz
      : lark < 10 ? lark
      : 0

Your wish can come true. Take a look at this stage 1 of the TC39 proposal. https://github.com/tc39/proposal-do-expressions

I would format that as either:

  var myvar =
    foo < bar ? bar :
    bar < baz ? baz :
                0

or:

  var myvar =
     foo < bar ? bar
   : bar < baz ? baz
   : 0

I love ternary operators, but nesting them is a recipe for turning your code into an unreadable mess.

The latter, IMO.

Something like

  Screen.oled ? "black" : "rgb(21,21,21)"

is easy enough to read. Beyond that, if statements win for me.

Personally I'm not a fan. A lot of people love using conditional operators (?, &&, ||) in React, but having overly nested chains of these operators is a code smell for me. Probably means they can refactor the logic into separate components, or into intermediate boolean variables. Or just into a plain old if statement.

Nope, even code with doubly, triply, or quadruple-ly nested if statements is typically hard to read. I usually refactor that down to avoid that level of nesting.

I don't think there's ever a good excuse for that much nesting of ternary operators.

I love them. I also just managed to mess up a function because of one and not realize it until a late stage of testing I don't know that I've doubly nested them.

IMO, that's awful and should never, ever be done.

If he's making the code hard to read, hopefully you can talk that through with him. It sounds like a reasonable concern.

Just wait until you learn about PHP's ternary operator.

It depends on the context. Declarative vs procedural. Ternary statements are 2:1 multiplexors.

The traditional method of measuring code complexity is Cyclomatic Complexity [1] which, roughly speaking, measures the number of branch points in the code.

[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity

IMO a good start would be to create a metric based on a combination of:

* Lines of code

* # of keywords/operators

* # of non-standard keywords/operators (i.e. 'go' versus 'if')

* Use of std. library vs. 3rd party libraries

* Depth of call-stack, i.e. is it passing through 3 parent classes

When comparing different languages it becomes more of a measure of the relative abstraction levels of languages. The exact same program will have hundreds (or thousands) of times more LOC in Assembly than in Python.

Not only that, the LOC heuristic depends on the verbosity of the language. Java, for example, is more verbose, than say, Python, even though you’re close in abstraction level.

And just syntax decision.

    if (x) {
        y
    }
    else {
        z
    }

    if x:
        y
    else:
        z

Assuming x and y are 1 line but long enough expressions you don't want to use a trinary operator (available in both) the python is 2/3rds the length of the c because of bracketing. Obviously cherry picked, but I bet these differences add up.

Of course, you can omit the braces if there’s a single statement (though I personally never do this).

Sure, and you can put the else on the same line as the end of the if block even without doing that. Or you could make the difference bigger by putting the opening brace on a newline.

I wrote the style of C that I actually write, but it's probably not fair for me to label it as a property of just the language.

I think it’s a fair point to bring up given that many people actually do write their code that way.

I agree, I hope I didn't come across otherwise, just wanted to clarify why I wrote it like that.

Or even use allman / gnu where opening braces are also on their own line.

Yes, but those people clearly have issues ;)

Reply on news.ycombinator.com