4 ms·
Seems 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
by watt 4y ago
Seems 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, half of line height would do.
2) Or other way around, if you have an empty line before function body starts, IDE could narrow the height a bit, because this does not need a full-size empty line. Actually I wonder if there are IDEs around that play with variable line height for empty lines.
The above would allow folks who feel they are starved for vertical space to condense the code more, without impacting others who feel they have plenty of vertical space, and would like to break the "wall of text" with white space breathers.
Currently Intellij (GoLand) will strategically fold the `if / return err` pattern that Go code is littered with, so the whole "keep it on single line" point is moot for somebody using an advanced IDE that automatically renders the code in way to reduce visual clutter.
- oweiler 4y agoEmpty lines let you split your code into assignment/initialization, logic and parameter validation, without requiring you to split everything into tiny functions.
- mvdan 4y agoI agree that empty lines can help. I've been careful to only remove empty lines which, in my opinion, don't help when structuring the code or making it more readable. If you have examples where gofumpt is being a bit too aggressive, I'd like to hear about them. I've corrected, and even removed, some of gofumpt's rules in the past thanks to user input.
- oefrha 4y agoI use gofumpt for all my go code (have been for at least two years), and I use empty lines for structure. Out of the tens to hundreds of thousands lines written, I don’t recall a single instance where an intentional empty line was removed. I doubt gp’s comment is based on experience. Another giveaway is the “seems” at the very beginning.
- olig15 4y agoMicrosoft have an extension for Visual Studio that does this (and also shrinks lines with {}), I use it every day. https://marketplace.visualstudio.com/items?itemName=VisualStudioPlatformTeam.SyntacticLineCompression2022 https://marketplace.visualstudio.com/items?itemName=VisualSt... (there’s been a version for the last few versions of Visual Studio too)
- epage 4y agoPut 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.
- devnullbrain 4y agoThe way you've described it is almost verbatim with how Google's C++ style guide puts it: https://google.github.io/styleguide/cppguide.html#Vertical_Whitespace https://google.github.io/styleguide/cppguide.html#Vertical_W...
- francislavoie 4y agoYeah. And when I write comments, I do it in explanation of the chunk of lines below which perform a particular idea. The newline after that chunk is necessary to break up the chunks to give room for another one below, etc.
- jay_kyburz 4y agoI 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.