-
Notifications
You must be signed in to change notification settings - Fork 18k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/gofmt: should handle function parameter indentation properly #11423
Comments
I recommend
Generally, indentation is done with tabs only. One could use two tabs in your suggestion but that seems odd (only place where indentation is changed in steps larger than 1). Using spaces is after a tab is unprecedented in gofmt. Unfortunate. |
Sorry if my use of space in my examples was confusing ... that was merely trying to control how the result would show, since tabs don't always show up the same in different editors/browsers/etc. I understand indentation is done with tabs only. I was not suggesting using spaces instead. I was just suggesting that function parameters to be indented more than the function body. Why do you think that seems odd? I believe this is very standard practice for most programming languages. Examples: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Function_Declarations_and_Definitions |
I'm aware it's standard practice elsewhere. It's also standard practice to never indent with tabs - or in other words: "standard practice elsewhere" is not a compelling argument... The formatting suggestion I offered does work and avoids the irregularity here - think of the parameter list as opening a scope: indeed, the parameters are part of the function's body scope, which is "temporarily opened", and then closed again (hence the outdent) for the result type, and the opened again (indent for body). It's very regular. It also works for named results, and it scales:
By scaling I mean for instance:
Leaving closed for now. |
Instead of this:
It should do this:
And yes, I know with this toy example I could just put all the arguments on one line. But sometimes when using external type names which can be rather long, it is unavoidable.
The text was updated successfully, but these errors were encountered: