go version go1.10.3 linux/amd64
Reviewing CLs showed lists of const bit-masks that were foo = 1 << 42, etc., all had redundant parenthesis around the (1 << 42). The author said they were copying similar ones in existing source. gofmt doesn't remove them. It does remove the outer pair of double ones, i.e. ((1 << 314)) in https://play.golang.org/p/V6jz7iKHJwt
I think simple cases like foo = (1 << 42) can always have them removed. That's the style followed by most of the stdlib, but not all. Having pointed it out on the CL, Martin M枚hrmann is fixing those other cases that influenced the author, e.g. https://go-review.googlesource.com/126775, but it would be nice if gofmt avoided the possibility.
I send CLs to make the style of internal/cpu consistent. I do not plan to rewrite any other occurrences in the Go std library.
/cc @griesemer
This can already be done with gofmt, as documented in the examples https://golang.org/cmd/gofmt/#hdr-Examples:
gofmt -r '(a) -> a' -w *.go
Perhaps the -s flag could take care of this, but I don't think that the regular gofmt is designed to do cleanups like these. All the changes that add or remove syntax should be done by -r or -s, following the current design.
Is there a standard list of -r that are applied to golang.org source for consistency?
The suggested -r '(a) -> a' rewrites more than I'm suggesting. It: anywhere the () are redundant. Me: the redundant () when they're outermost on an ExpressionList.
I agree that this could be done if the -s option is given, but not otherwise.
Most helpful comment
This can already be done with gofmt, as documented in the examples https://golang.org/cmd/gofmt/#hdr-Examples:
Perhaps the
-sflag could take care of this, but I don't think that the regulargofmtis designed to do cleanups like these. All the changes that add or remove syntax should be done by-ror-s, following the current design.