Hacker News Reader

Comment by acdha | Hacker News Reader

I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks.

I'm now inclined to believe that a basically free way to avoid bugs and make things like code review easier and more productive is worth the minor cost of people having to break out of old ruts.

View on HN

Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err := foo(); if err { ... } that I get lost trying to figure what the happy path behavior is.

    > I get lost trying to figure what 
    > the happy path behavior is.

The happy path is idiomatically at indent level 0.

Except when it's

    if x, err := doSomething(); err != nil {
    }

...the happy path there is intend level 0?

    if err := doSomething(); err != nil {
        return fmt.Errorf("something failed: %v", err)
    }

Or,

    x, err := doSomething()
    if err != nil {
        return fmt.Errorf("something failed: %v", err)
    }
    
    log.Print(x)

I'm hoping Go's error handling is improved in 2.0. I understand the objections to Java-style exceptions but I think they underestimated the actual cost of having so much boilerplate clogging up every non-trivial program, not to mention the way it actively encourages people to punt on error checking which is why so many projects are littered with `x, _ := foo()`.

The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.

Again. Third party tools will have exactly the same benefits.

People have been using standard code formatters in Eclipse/IntellIj for what decades now ?

> a single standard format

indeed. Pretty sure there's some cognitive load involved for developers who come onto a team who uses a style that's different to what that developer is used to. Languages with strict style standards remove this problem.

Unless you change the settings it'll default to the Java Conventions.

> Again. Third party tools will have exactly the same benefits.

If that were true, the frictional problems I mentioned would not be the rule in every other language. Even something like Python, where PEP-8 has been recommended strongly by the community for many years and has widely available validators and automatic reformatters, still has perpetual low-level debates about this.

In languages like C, where there are multiple well-established conventions, you can still find bitter arguments going on over things like optional braces because there are still tons of bad programmers out there who think it's preferable to ship massive bugs every few years than type two extra characters.

Reply on news.ycombinator.com