gofmt should have an option to enable putting left brace/parenthesis on the next line

[gopherbot]

by [email protected]:

gofmt should have an option to enable putting left brace/parenthesis on the
next line.
I find this coding style more readable:

func (p *printer) writeNewlines(n int)
{
        if n > 0
        {
                if n > maxNewlines
                {
                        n = maxNewlines
                }
                p.write(newlines[0:n]);
        }
}

I made a modification that adds option -nextline to gofmt. See attached patch.

Attachments:

1. gofmt_nextline.patch (2406 bytes)

[gopherbot]

Comment 1 by cbraid:

ugh.. that's just sooo many more lines to express the same thing ;)

[gopherbot]

Comment 2 by a.chavasse:

Newline characters are cheap these days, and today's monitors are large enough to
accommodate extra lines for improved readability :)

[gopherbot]

Comment 3 by peterbourgon:

While I personally find the BSD-style braces much more readable as well, Go's authors
seem fairly set in sticking to the existing gofmt style:
> We hope that people will accept the output of gofmt precisely
> because it puts an end to these kinds of style debates.  How
> many different brace styles are there in C?  Too many. 
http://groups.google.com/group/golang-nuts/browse_thread/thread/1c2dac0e1ad95b96

[agl]

Comment 4:

(for the reasons outlined above.)

Status changed to WontFix.

[gopherbot]

Comment 5 by a.chavasse:

That's a matter of user preference. People have different ways of thinking and I don't
see what is the big 
deal to let people format their own code the way they want.
I too would enjoy being able to solve any problem I have by telling people "hey, let's
just do it my way - 
problem solved" but it cannot work in practice.
People will just end up maintaining a separate version of gofmt that allows more
flexible configuration. I 
know that if no one else do this, I will. Being able to have good readability in my own
code is more 
important to me than other people's desire for uniformity.

[gopherbot]

Comment 6 by [email protected]:

I don't understand the reasoning. I am not asking you to make this default.
I just want to have a choice (there already are few options - spaces vs. tabs etc.,
so this is no break-in attempt).
That's what open source is all about - make default setup, call it a standard, but
still let people choose their own way. Please don't push your de facto standard by
force. That would be counterproductive.

[gopherbot]

Comment 7 by Cryptooctoploid:

Yes its open source. Go wild and do whatever you want
on _your_ machine. But there is no obligation on Google's side
to apply your patch at all.

[gopherbot]

Comment 8 by SRabbelier:

Actually, forcing your own de facto standard by force is not at all counterproductive. 
Research on coding styles shows that using a consistent coding style results in faster 
reading. That is, experienced coders can read code faster if it follows the coding 
style they're used to.

[gopherbot]

Comment 9 by a.chavasse:

Using a consistent coding style makes sense at the project level, not at the language 
level. As you say yourself, "experienced coders can read code faster if it follows 
the coding style they're used to" - it doesn't work if they can't use the coding 
style that they're used to in the first place.
At the end of the day, coding style is a matter of personal preference and it's just 
unrealistic to expect to make everyone on the planet to agree upon a certain style. 
It's possible within the confine of a development team though, and that's where the 
decision should be made.

[gopherbot]

Comment 10 by [email protected]:

> Actually, forcing your own de facto standard by force is not at all counterproductive.
Let me explain.
This patch does not touch any current functionality. It just adds a new optional
feature. If you had choice, what gofmt flavour would you use supposed both are
equally reachable ? The one than can does less or the one that can do more without
any trade-offs ?
Now remember that most users won't install Go from source. They'll install it as some
kind of binary package from their OS repository. If upstream doesn't accept enhancing
and harmless patches from community, package maintainer usually applies patches of
his/her choice to upstream source because he/she usually wants the users to have more
options, not less.
As a result, every distro will use slightly different Go flavour and those little
annoying differences will make resolving bug reports very hard and it won't be clear
if a bug is related to upstream source or applied patch.
I perfectly understand Google has right to refuse any patch. The are plenty of
reasons for not accepting a patch - bad code quality, standard coding style
violation, duplicated functionality, API misuse... All those reasons have one in
common: they give a hint what should be made to implement desired functionality in a
proper way.
The reason for not accepting this patch is: We don't want users to use such
functionality.
I think such paternalizing approach won't help Go authors to achieve their dream of
uniform coding style. It will just produce incompatibilities without any real profit.
Developers tend to stick to their habits even at the price of deviating from upstream.