FAQ
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

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Dec 20, 2013 at 6:11 pm

    On Dec 20, 2013 12:58 PM, "Josh Bleecher Snyder" 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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kamil Kisiel at Dec 20, 2013 at 9:08 pm
    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.

    On Friday, December 20, 2013 9:57:28 AM UTC-8, Joshua Bleecher Snyder 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.

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alex Skinner at Dec 20, 2013 at 9:23 pm
    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

    On Friday, December 20, 2013 12:57:28 PM UTC-5, Joshua Bleecher Snyder
    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.

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alex Skinner at Dec 20, 2013 at 9:25 pm
    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
    On Friday, December 20, 2013 4:23:44 PM UTC-5, Alex Skinner wrote:

    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

    On Friday, December 20, 2013 12:57:28 PM UTC-5, Joshua Bleecher Snyder
    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.

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Dec 20, 2013 at 10:48 pm

    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).

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Bleecher Snyder at Dec 20, 2013 at 11:45 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Bleecher Snyder at Dec 21, 2013 at 2:38 am
    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


    On Fri, Dec 20, 2013 at 3:45 PM, Josh Bleecher Snyder
    wrote:
    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Zeebo at Dec 20, 2013 at 9:38 pm
    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:
    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Grilly at Dec 20, 2013 at 9:51 pm

    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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Bleecher Snyder at Dec 20, 2013 at 10:22 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 20, '13 at 5:58p
activeDec 21, '13 at 2:38a
posts11
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase