Three blank lines before comments and two blank lines after comments make for excessive scrolling.

[norru]

Thanks for your work, this is a neat tool, I'm currently evaluating it with elm-light.

This is a suggestion/rant rather than a bug report. Feel free to ignore.

I am new to Elm and I generally prefer a compact style in (many) other languages to avoid scrollfests of very sparse code in a sea of whitespace. While I can understand the "readability issues" most people try to solve with this approach, three blank lines before a one-line comment and two lines after seem a bit excessive to me.

Is there a command line switch to limit the number of consecutive blank lines?

Currently, this is a deal breaker to me. At the moment I have a few uncompelling options:

• postprocess with sed/awk to remove the lines in excess
• go full lo-tech, forgo the automatic formatting altogether
• purchase a spacebar woodpecker like this: http://www.thinkgeek.com/product/981b/
• drop lighttable and go for Emacs's tab-indent
• fork

Suggestions?

[rtfeldman]

Hi @norru,

Elm started out in a more compact style and evolved here based on a priority of making code easier to read.

Usually if you have a one-line comment outside the context of a function definition, it is to separate logical sections of a file, e.g. -- Query Helpers --, and in that use case, having newlines around them is what you want. (Although as an aside, 3 before instead of 2 before may be a bug.)

Every time I've had this happen to me in elm-format and felt that it was annoying, I've asked myself, "is this the best place for this comment?" Then I promptly realized that the comment would make more sense inside the body of a function, or as a documentation comment (that is, putting {-| Some documentation goes here -} above the function) instead. Now I've just gotten in the habit of doing that, and I've found my code is better for it.

My two cents. :smile:

[renatorozas]

@rtfeldman

Every time I've had this happen to me in elm-format and felt that it was annoying, I've asked myself, "is this the best place for this comment?" Then I promptly realized that the comment would make more sense inside the body of a function, or as a documentation comment (that is, putting {-| Some documentation goes here -} above the function) instead.

Ok, you have a point right there. I was going to complaint about the same thing but I'll give it a try and make my comments better.

[jeremy-w]

I figured it for blindly enforcing the "two blank lines before a top-level definition" rule without taking the non-doc-comment into account. I note that in the Elm Architecture Tutorial's examples (such as RandomGif), components are split into model/update/view/effects major sections with all-caps comments having two blank lines before but only one following. I found this nearness (one rather than two blank line) useful in visually attaching the header as a header rather than simply a separator; I think I saw 2 before and 2 after in my use of elm-format, which destroyed this header-ness, to the detriment of the code's comprehensibility.

That said, I'm finding that many prefer to split the TEA-leaves, which are found in that example in one file, into a file per section within a component directory. If that's the direction things are heading, then it's less of a concern, but I found that degree of sharding for small components made for a lot of file management with little gain.

[onemanstartup]

I think it should be stated somewhere. If formatting is styleguide for all it should be clearly stated why some comments adds new blank lines and some are not. I am just starting with elm and I copied examples in editor and formatter gave me huge amount blank lines.

{-| some comment
-}
somefun =

This formatting of comments should be padded with blank lines.

-- some comment
somefun =

And this short comment should not. IMHO

[rtfeldman]

Based on this discussion, and my personal experience, I think it's worth making the single-line case for doc comments actually single-line. In other words, go from this:

{-| some comment
-}
somefun =

...to this:

{-| some comment -}
somefun =

I remember Evan's original reasoning for this being that it makes it easier to expand the docs to multiple lines later.

I think that's a sensible thing to encourage if you're writing thorough documentation for public APIs (as he generally is), but if you're just adding a short bit of documentation to an internal function—something like {-| if you need to do the reverse of this operation, see the fooBar function -}—it seems correct to do it as a doc string (as it is, after all, documenting the function) that takes up a single line (since expanding it to multiple lines would be pointlessly verbose).

There's also a "minimize diffs when going from one-line to multiline" argument, but switching to multiline just adds an extra +-} to the diff, and it's consecutive with another diff that's already necessarily multiple lines, so I don't think there's actually any benefit there in practice.

Overall, this seems like it would make code look nicer and have no real drawback.

[kjozsa]

As another newcomer, I tend to agree with the original poster. I got here googling "elm-format blank lines" and did so for a reason :) The auto-formatter is a cool feature but the 3 + 2 blank lines around comments are really disturbing for new arrivers I think.

[stevenyap]

+1 for the doing away with the excessive blank lines... keeping it concise is much better...

I come from the javascript prettier and found that the current elm format has too much white spaces due to the excessive blank lines

[norru]

Oh, hello, necroposting! ;) No longer working on the project above, but, if it helps, I seem to remember that I did solve this problem by using a simple bash script wrapper and a sed one-liner to remove all double and triple consecutive blank lines.

[norru]

Found in my attic

#!/bin/sh
# rename original elm-format to elm-format.bin
# replace with this and chmod +x
elm-format.bin $*
sed -i '/^$/N;/^\n$/D' $2
echo elm-format.bin $* >> elm-format.log

[robx]

I came here wondering why my "doc comments" were moved away from the function. (I'd been using a normal comment as function documentation.)

I'm okay now with the solution of using {-| -} comments, however this could really be documented better, and brought inline with the core elm documentation, e.g., https://elm-lang.org/docs/syntax#comments.