V: Keep empty lines when running v fmt

[bombsimon]

v fmt removes all empty lines added by the developer in the code. This issue is to collect and keep track of the discussion whether or not v fmt should remove the empty lines. Personally I think newlines add a lot of value to the code and highly improves readability. Others think it's code smell. It would be possible to write v fmt in such a way that it even adds newlines at specific places such as between blocks or before return statements.

I definitely feel like it's in line with the v style of a strict pragma (such as fail compile with bad varaible names #3707) which I think is good, I just don't agree with the decision this will be the best for the language.

So far, the discussion has been something like this (very generalised and a somewhat bad TL;DR):

Pros with removing newlines

• It hints the developer to make smaller functions and keep separation of concerns
• It hints the developer to add comments documenting the code to keep separation
• It's hard to make code look consistent since people tend to add newlines at different places

Cons with removing newliens

• It makes the code harder to read^{[citation needed]}
• It makes it harder for the developer to structure the code in a desired way
• It makes it easier to write bad/faulty comments just to add code separation

---

If you pass by this issue and have an opinion regarding newlines, please add your reaction to show what you prefer!

• 👍 - Keep empty line(s)
• 👎 - Remove all empty lines

[spytheman]

I personally very much like to have single empty lines as separators in key places, instead of being forced to use empty lines with just '//' in them. I think empty lines are more readable than empty lines with just '//' in them.

Thus said, that would make the scanner more complex (it would need to store information about how many newlines were there, while currently it simply skips any whitespaces between the tokens). I can not see right now an easy way to implement support for keeping the empty lines, without slowing down the scanning/parsing :-| .

[bombsimon]

Keeping the code exactly as is doesn't require the scanner/parser to change, although if you only want to allow one newline and e.g. change places with three empty lines to one (like go fmt), I guess it's trickier. I don't think it's equally important for v fmt to be as quick as the compiler though so I'm not sure if I see any risk regarding performance.

[elimisteve]

It would be possible to write v fmt in such a way that it even adds newlines at specific places such as between blocks or before return statements.

Hmmm, good point. This would keep code readable in the ways that you describe (I agree) while also achieving the goal that @medvednikov has mentioned of making all V code uniform, without everyone's weird little personal extra-newline preferences being sprinkled about (though I don't think this is really a "problem" that needs solving).

Overall, I say: if there is a newline insertion strategy/format that can be widely agreed upon, that works for me, otherwise let's please just do what go fmt does.

[spytheman]

Currentlyv fmt and v the compiler share the same scanner/parser @bombsimon .

[Gladear]

Although I don't really have any objective argument to support my cause, I would really love enforced empty newlines.
Only one block of code looks hard to read to me, and you would still get code consistency across projects !

[medvednikov]

Ok, this will be implemented. Multiple newlines will be replaced with one newline.

[JalonSolov]

... except at the very beginning of the file, or the very end.

There shouldn't be any blank lines at the beginning, and there should only be a trailing EOL on the last line, but no blank lines after.

Anyone disagree?

[ChildishGiant]

Is there scope to add a vfmtrc for setting these kind of things? I think lots of this is developer preference and many linters/formatters do this.

[JalonSolov]

That's not "the V way". Just like go fmt always formats your source exactly one way, v fmt will do the same.

People used to complain like crazy about Go forcing the format of your files to "their" way... but over time, it has proven to be a great thing - since all code is formatted the same way, it is very easy to read someone else's code.

Unlike most other languages, when the first thing I have to do is run someone else's code through my own formatter just so I can read their code more easily.