Hacker News Reader

Comment by lmm | Hacker News Reader

Extra braces add visual clutter and reduce readability, especially when they mean a function no longer fits on one screen. So if there's a way to eliminate that kind of bug without having to add more braces then I'm all in favour of it.

(Personally my preference would be a linter that automatically runs on checkin, and refuses commits that do not conform to the style guide)

View on HN

> add visual clutter and reduce readability

one person's clutter is another person's markers. I wouldn't agree they reduce readability

> when they mean a function no longer fits on one screen

What screen size? What resolution? What ide/editor window size? What font face & size? With or without soft line wrapping?

Honestly arguments about how "pretty" code is are fucking ridiculous. Despite what someone said, the purpose of source code is not to be "read" with "running" as a secondary task. That literally only applies to code written purely for educational purposes.

The purpose of code is to achieve the goals of the software as efficiently as possible. Efficiency is not just about speed - a fast but unreliable program is not efficient.

> What screen size? What resolution? What ide/editor window size? What font face & size? With or without soft line wrapping?

Does it matter? There will be a point at which an extra line makes the difference. And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space.

> Honestly arguments about how "pretty" code is are fucking ridiculous. Despite what someone said, the purpose of source code is not to be "read" with "running" as a secondary task. That literally only applies to code written purely for educational purposes. > The purpose of code is to achieve the goals of the software as efficiently as possible. Efficiency is not just about speed - a fast but unreliable program is not efficient.

The ability to understand software is vital to real-world usefulness though. Requirements change all the time, and so the ability to make changes to software is vital - and to effect desired changes to code you must first understand it.

> And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space.

What? Modern 10:16 screens give more lines than 3:4. 900x1440 gets like 70 lines with 100 columns at a decent font size, better than around 60 lines with 110 columns with 960x1280.

Good luck using your laptop vertically.

As I said in the other thread I'm not talking about readability.

The exact term used was pretty.

> There will be a point at which an extra line makes the difference

So why not remove all blank lines too. They're less important for reducing issues that single line/braceless flow control blocks can cause.

> So why not remove all blank lines too. They're less important for reducing issues that single line/braceless flow control blocks can cause.

By and large I do. But I don't think what you say is actually true. Given the choice between:

    stepa1
    if(something)
      stepa2
    stepa3

    stepb1
    stepb2
    stepb3

and

    stepa1
    if(something) {
      stepa2
    }
    stepa3
    stepb1
    stepb2
    stepb3

(same number of lines), I think the former is often more readable - stepa2 is visually separated in either case.

If the code can't be read, then it really doesn't matter how it runs because no one will understand it well. Trust me. Some of the code I work with has this problem. I fix it when I can, but there's just too much to fix it all.

The only code where readability isn't as important as functionality is finished code, and we all know that code is never finished.

I didn't say readability doesn't matter.

I'm talking about people who skip braces on single statements, skip semicolons in JavaScript, etc because it "looks prettier" without them

Reply on news.ycombinator.com