gofmt and leading/trailing blank lines within functions

[Josh Bleecher Snyder]

Hi all,

My formatting OCD makes me want gofmt to remove leading and trailing
blank lines within a function. For example, in
http://play.golang.org/p/Np4vGQFcqA, I'd want gofmt to remove lines 6
and 13.

Before I go file an issue, though, I wanted to run it by y'all to see
what I might be missing.

Are there scenarios in which leading or trailing blank lines serve a
useful semantic role, as interior blank lines can? Are there scenarios
in which they play an important role in readability?

Thanks!

-josh

[minux]

On Dec 20, 2013 12:58 PM, "Josh Bleecher Snyder" <josh...@gmail.com> wrote:
>
> Hi all,
>
> My formatting OCD makes me want gofmt to remove leading and trailing
> blank lines within a function. For example, in
> http://play.golang.org/p/Np4vGQFcqA, I'd want gofmt to remove lines 6
> and 13.

godoc is trained to respect the existing grouping of statements, perhaps this is a side-effect of that.
i think it can remove the empty lines here.

> Before I go file an issue, though, I wanted to run it by y'all to see
> what I might be missing.
>
> Are there scenarios in which leading or trailing blank lines serve a
> useful semantic role, as interior blank lines can? Are there scenarios
> in which they play an important role in readability?

i cannot think of any. but others might.

[Kamil Kisiel]

Sounds good to me, so long as things like:

func foo() {

    // Some comment here

    // More comment

    doSomething()

}

remain unchanged. 

Occasionally it's nice to have a comment documenting some implementation details to lead the function and the blank line

serves as a good visual separator.

[Alex Skinner]

I'd prefer it not do that, honestly.  It would have to be context aware, which would likely be more trouble than it's worth.  Sometimes I've used a blank line to separate 'thoughts' inside a function, to make long comments more readable.  In bigger programs, when adding something temporarily, I'll often leave multiple blank lines around a "loud" comment so that I can find it later and remember to do it.  Removing those blank lines I think would hurt me there.  I would not be opposed to be being an optional flag, however.  Just my $.02.


Alex

[Alex Skinner]

Apologies, I misread the initial proposal, thinking it was to remove all blank lines!  As long as it's only leading and trailing blank lines in a function, I'd be on board :).

Alex

[zeebo]

I'd prefer not to. Sometimes wrapping function declarations makes it easier to read and the newline helps distinguish the function declaration from the body: http://play.golang.org/p/E2ygXulXeD

On Friday, December 20, 2013 12:57:28 PM UTC-5, Joshua Bleecher Snyder wrote:

[Nicolas Grilly]

On Friday, December 20, 2013 10:38:01 PM UTC+1, zeebo wrote:

I'd prefer not to. Sometimes wrapping function declarations makes it easier to read and the newline helps distinguish the function declaration from the body: http://play.golang.org/p/E2ygXulXeD

I agree with zeebo. 

[Josh Bleecher Snyder]

> I'd prefer not to. Sometimes wrapping function declarations makes it easier
> to read and the newline helps distinguish the function declaration from the
> body: http://play.golang.org/p/E2ygXulXeD

Thanks, that's the sort of thing I was looking for; makes sense.

Leading blank lines in the case of a multiline function declaration
could be left in. With that exclusion in place, does it now seem ok?

-josh

[Kevin Gillette]

On Friday, December 20, 2013 2:23:44 PM UTC-7, Alex Skinner wrote:

In bigger programs, when adding something temporarily, I'll often leave multiple blank lines around a "loud" comment so that I can find it later and remember to do it.

Traditionally, `// TODO`, `// BUG`, `// XXX`, and so on have been used to do what you're describing. 

On Friday, December 20, 2013 2:38:01 PM UTC-7, zeebo wrote:

I'd prefer not to. Sometimes wrapping function declarations makes it easier to read and the newline helps distinguish the function declaration from the body: http://play.golang.org/p/E2ygXulXeD

I personally don't agree with that style of signature wrapping, or the use of naming or design that usually leads to such long signatures (yes, there are what I would consider legitimate exceptions, but they are exceptionally few in number). However, the existence of any disagreement is enough for me to feel that this aspect of gofmt should remain as is. Unlike manually managing field alignment or, to lesser extent, indentation, those extra lines only exist because of humans, and are trivial to remove by humans, thus having gofmt remove these lines doesn't actually save anyone a lot of time (and that time could be pre-saved by not putting those blank lines in to begin with).

[Josh Bleecher Snyder]

> However, the existence of any disagreement is enough for me
> to feel that this aspect of gofmt should remain as is.

Agreed...although I would scope "this aspect" to be very narrow,
namely just around multiline function declarations.

> Unlike manually managing field alignment or, to lesser extent, indentation, those extra
> lines only exist because of humans, and are trivial to remove by humans,
> thus having gofmt remove these lines doesn't actually save anyone a lot of
> time (and that time could be pre-saved by not putting those blank lines in
> to begin with).

gofmt already deals with vertical whitespace; for example, it
collapses two consecutive blank lines into one. This is wonderful for
all the usual reasons. The proposal at hand is, I believe, not
substantively different.

-josh

[Josh Bleecher Snyder]

Thanks all for the feedback--thoughtful and insightful, as usual. I've
filed https://code.google.com/p/go/issues/detail?id=6996 for this.

-josh