Hacker News Reader

Comment by mden | Hacker News Reader

Eh, all things equal, the less the number of lines the more readable.

I disagree. Consider the absurd example where every single statement is crammed into a single line. Not exactly readable to me?

Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.

That's covered by "all things equal".

The argument against placing braces on their own line is that this:

    if (a)
    {
        print(a)
    }

conveys exactly as much information as this:

    if (a) {
        print(a)
    }

while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.

> The thing the brace tells you is already told by the indentation

Which is true, and of course begs the question: why do you even need the braces?

1) I frequently tell my diffs to ignore whitespace so I can see my structural changes without getting drowned in a sea of indentation changes when introducing new scopes. Not viable when diffing python.

2) I semi-frequently make indentation mistakes when resolving merge conflicts. In braced languages this is fixed by an autoreformat. In unbraced languages, I have to take a lot more care with merging, lest I end up in yet another lengthy debugging session ending in facepalms - or worse, check it in.

3) Redundancy in the face of typos and whitespace destroying mediums such as many pieces of web technology - comments sections, forums, etc.

In this specific case

    if (a) {
        print(a)
    }

and if (a) { print(a) }

Could just be if (a) print (a)

Except in perl, where it's

    print (a) if (a)

And if you want to add a second line you have to change it, thus I got into the habit of

    if (a) { print(a) }

But I don't code for a living, any more than I run network cables for a living, or screw things into bays for a living. I code as a tool to get the job done, most recently that was writing some perl to parse the output of a tcpdump which was outputting rtp sequence number discontinuities to see where packet loss was occurring, what jitter was going on, etc. Fast, to the point, isolate the problem (crappy juniper srx), fix the problem (replace with mikrotik ccr), job done, drink beer.

I do like one-liner conditionals (at least short ones for early bailout) but sadly my coworkers and their coding standards do not.

Off-topic and pedantic pet peeve, would you mind replacing "begs the question" with "raises the question". The former might not mean what you intended.

Maybe it's just me, but I find the first version easier to parse visually. When the coding convention forces me to put the brace on the same line, I end up doing:

    if (user.exists()) {

        destroyHuman(user);
        hideRemains(user);
    }

Reply on news.ycombinator.com