Hacker News Reader

Comment by K0nserv | Hacker News Reader

This looks really nice. One of my favourite things about Golang is the use of gofmt and the resulting consistency of all Go programs. The idea of parsing the code to AST representation and then printing it back as source is brilliant, all though it can mess stuff up like the chaining of `.then` as mentioned in the post.

View on HN

I completely agree. What is, for most programming languages / code, a huge waste of time and huge amount of annoyance becomes something you no longer have to deal with.

Having choices can be nice, but it introduces a huge amount of cognitive load. And, really, if we all just use the same format, we'll all (eventually) get used to it.

We really do have better things to deal with than formatting style.

It also helps if you want to write code conversion tools, like gofix. I once stopped writing such a tool for a Python project because it was a pain trying to change only the affected lines, while keeping the idiosyncratic syntax of the rest of the files unaffected.

(By the way, for people trying to do the same, I recommend the redbaron library, which makes it much easier to handle: https://github.com/PyCQA/redbaron)

gofmt doesn't solve the hard problem that this blog post (and Wadler's paper) is about. From the article: "There's an extremely important piece missing from existing styling tools: the maximum line length."

gofmt's decision to not bother to require a line length may work somewhat for Go (which tends to encourage short lines by virtue of lacking expressiveness), but it doesn't work for lots of other languages, including JavaScript.

Yeah that's a good point. I was referring more the general idea of enforcing style by parsing the code and reconstructing the source from the AST though. This is a better method than the linter approach that you get with eslint for example.

The fact that gofmt doesn't enforce some arbitrary line length is a blessing. I have a modern widescreen monitor and I use a maximized window text editor. I have no problem with 200 char length lines. I'm more easily annoyed by 80 (or 60, like in this case) char limits, as if I was viewing this code on punch cards.

It can be configurable. The rust community for example sticks to 100 or 120 lines (and rustfmt lets you choose).

I have big screens but side by side diffs on unformatted code on GitHub are always wrapped. Plus I often split my screen. Not everyone uses maximized windows all the time, and in a shared codebase sometimes you want to try and cater to everyone.

> The fact that gofmt doesn't enforce some arbitrary line length is a blessing.

You don't have an infinitely long screen. You have some line length limit.

It's infinitely scrollable though. Scrolling horizontally sometimes isn't a bad fallback.

Scrolling horizontally interrupts flow like nothing else!

99% of all software projects have a de facto or de jure line length limit for a reason.

You don't usually code for one screen since you're not generally coding for yourself alone. IMHO unlimited line length + editor soft-wrap is the best way to deal with the problem since it automatically adjust the size to the reader's screen.

Same for tabs for indentation[1], that allows the reader to set its own indentation width depending on its own preferences.

I don't really understand why people keep using spaces + fixed line length. Old habits die hard I think.

[1] tabs for indentation, space for aligning

That's exactly how I feel about it. Line length is something I couldn't care less about. If it makes sense to be on one line, then it should be. Otherwise, create the new line where it does make sense.

I like to divide my screen into multiple windows each 80 or 90 columns wide, so that I can see several source files at the same time, or code and documentation and shell windows.

Line length limits help me to make really effective use of big screens.

Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.

Theoretically, an editor could. I have yet to see one that does this well. Most do dumb wrapping, with no language sensitivity.

I think it's just a matter of programmer habit now -- folks expect their editor to mirror the code without formatting tweaks.

It gets confusing when you realize that programmers may insert their own indentation and wrapping, and sometimes you want to make this part of the actual file, and sometimes you want to remove it before serializing.

I've been pretty happy with vim and "set breakindent" where the broken line is indented to the parent one. I pretty frequently work with small views of a file.

> Why does the formatter need to solve this and not the editor? The editor has more information available to it, like the present screen space.

Because making the line wrapping nice requires deep syntax-aware editor integration. Most languages try to be at least somewhat plain-text-editor-friendly.

> Because making the line wrapping nice requires deep syntax-aware editor integration.

Why does it need to be syntax aware?

Think what happens when you break a line comment (or a string, in languages where it can't span several lines). And that's an easy example at that.

What happens? Nothing as far as I'm aware. The code is still one line.

> Because making the line wrapping nice requires deep syntax-aware editor integration.

'nice' is the key word here

I wish more people would realise this.

Reply on news.ycombinator.com