Notably, this stricter formatter still doesn't take a stance on line length.
and thank goodness for that
Gofumpt: A stricter gofmt
81–90 of 93 posts
Re: Gofumpt: A stricter gofmt
#82Good. Go deserves this. Before gofmt, programmers were allowed to have accents. Teams were allowed to decide their preferred style. Since gofmt, we "avoid bikeshedding" by disallowing the developer from adding any value via formatting. Dozens of languages that are far more sophisticated than Go have adopted this boneheaded approach (typical Go philosophy) in the years since gofmt appeared. It'll be a while before I r…
I personally am looking forward to the go tool replaces `go run` etc. for a version that makes additonal whitespace and misalignment into a compiler error!
this but actually earnestly yes
Re: Gofumpt: A stricter gofmt
#83Gofumpt? Is that Ftumch's cousin? :P
Re: Gofumpt: A stricter gofmt
#84Related prior discussions:
Gofmt No Longer Allows Spaces. Tabs Only - https://news.ycombinator.com/item?id=7914523 (2014, 56 comments)
Refactoring with go fmt - https://news.ycombinator.com/item?id=6724775 (2013, 40 comments)
Researchrsc: Gofmt - https://news.ycombinator.com/item?id=996934 (2009, 34 comments)
Tangentially related:
Psychological effects of coding style (2016) - https://news.ycombinator.com/item?id=22992914 (2020, 71 comments)
Re: Gofumpt: A stricter gofmt
#85Re: Gofumpt: A stricter gofmt
#86See also: interfacer - Automatically Suggest Interface Types in Go https://github.com/mvdan/interfacer https://news.ycombinator.com/item?id=11397905 (9 comments) shmfmt - A shell parser, formatter, and interpreter with BASH support https://github.com/mvdan/sh (Submitted often but not yet discussed) --- /me whispers: Hint: You could be that guy [1] (or gal, they, it, etc): /submit shmfmt Feel free to leave a link to y…
Ah well, maybe next time :)
Looks like next time is in fact happening now :D
Shfmt – format shell programs (like gofmt, rustfmt)
https://news.ycombinator.com/item?id=34754116
@typical182 - thanks for doing the thing!
Re: Gofumpt: A stricter gofmt
#87Earlier quoted context omitted.
Take PEP8 for example which is Python specific. PEP8 has a rule that code shall not exceed 79 characters. This has the added benefit that on a standard 1080 monitor you can see two Python files side by side without horizontal scrolling. This also has the added benefit of being able to see code diffs without issue. I can see why certain choices are made but only matter if they have sound reasoning and arguments for th…
> This has the added benefit that on a standard 1080 monitor you can see two Python files side by side without horizontal scrolling. Isn't that a function of font size rather than screen resolution?
You really want to argue that shrinking font from a standard font size will produce legible text like that?
The argument is against super long lines. I think Clean Code suggests something similar to the effect of if you have more than three arguments for a method you are better served taking a class as the argument.
Re: Gofumpt: A stricter gofmt
#88Earlier quoted context omitted.
> disallowing the developer from adding any value via formatting formatting doesn't add value. no one formatting is going to please everyone, so it follows that any formatting is going to piss someone off. So I think the point from the Go team is to remove that distraction and let people focus on whats actually important, the code itself.
Someone never had to write a matrix
you mean a single dimension array pretending to be a multi dimensional array? no thanks.
Re: Gofumpt: A stricter gofmt
#89Seems a lot of these rules focus on removing empty lines. I find empty lines let the code "breathe" a bit. Without them, it's a massive wall of text, sometimes. Well, often times. It's interesting you can address the "wall of text" problem in 2 ways. 1) Get IDE strategically insert vertical whitespace, for example right after function definition, and before function body. It does not need to be a full empty line, hal…
Put another way, writing clean code is like writing prose. You need to clearly break down your thoughtt, whether its sections, paragraphs, sentences, and fragments, or files, functions, blocks, groups of lines. Drove me nuts when working in a C# code base that controlled newlines because I had to break up related thoughts.
I really hate the c# code style of a new line for both open and close braces, especially in an if then else statement. Pushes people to use long ternary statements instead.
I prefer ifs to ternarys because, more often than not, I want to easily add and remove statements to the body of the then or else as I'm working things out.
Re: Gofumpt: A stricter gofmt
#90Earlier quoted context omitted.
As far as I understand, that's a consequence of the automatic insertion of trailing semicolon by the lexer, not a decision by gofmt. It's explained here: https://go.dev/doc/effective_go#semicolons
I see. That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition.
> That doesn’t seem very sensible in potential-beginning-of-block contexts, in particular in the if case where an implicit empty statement is deduced after the condition.
Are you referring to C style if statements where you can elide the braces?
In go the braces are mandatory, so I don't think that really applies.