Introduce Go coding standards for LLVM.

[pcc]

Summary

Rather than define our own standards, we adopt a set of best practices that
are already in use by the Go community.

[ruiu]

You may also want to have a link to https://code.google.com/p/go-wiki/wiki/CodeReviewComments.

[pcc]

Add link to Go Code Review Comments

[ruiu]

LGTM but I don't think I'm the decider on this.

From the Go programmer's point of view, this is a welcomed policy. It's widely accepted that there's one Go coding style and no more than that. Suggestions to make another policy or alter the default policy usually get strong pushbacks.

[rnk]

docs/CodingStandards.rst

182–184 ↗

(On Diff #14827)

We should probably just say that none of these conventions apply to non-C-family languages. Our Python bindings and lit are basically PEP8 style, for example.

[chandlerc]

I think this is fine. I'd like to see Reid's comments addressed, but I don't think this patch is really a step backwards in any sense.

docs/CodingStandards.rst

182–184 ↗

(On Diff #14827)

I'm fine with clarifying that in a further patch if you want, but I also think its totally fine for us to actually state that Go code, if it exists in LLVM, should follow the gofmt and idiomatic patterns documented by the Go folks.

[ruiu]

docs/CodingStandards.rst

182–184 ↗

(On Diff #14827)

But if we don't say anything about the coding standard, it would be continually raised what new code should look like. Because we are going to check in considerable amount of Go code as a Go frontend written in Go, I'd like to have a clear rule here.

[chandlerc]

docs/CodingStandards.rst

182–184 ↗

(On Diff #14827)

I mean, I agree that we should say something and something specific for Go. We can *also* say that any languages not covered explicitly here should <something_i_haven't_thought_about>, but it seems fine to add explicit guidance for Go now.

[pcc]

Closed by commit rL219646 (authored by @pcc).

llvm/trunk/docs/CodingStandards.rst

 system, your best approach is to minimize your use of these features, and watch
 the Linux build bots to find out if your usage triggered a bug. For example, if
 you hit a type trait which doesn't work we can then add support to LLVM's
 traits header to emulate it.
 
 .. _the libstdc++ manual:
   http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/manual/status.html#status.iso.2011
 
+Other Languages
+---------------
+
+Any code written in the Go programming language is not subject to the
+formatting rules below. Instead, we adopt the formatting rules enforced by
+the `gofmt`_ tool.
+
+Go code should strive to be idiomatic. Two good sets of guidelines for what
+this means are `Effective Go`_ and `Go Code Review Comments`_.
+
+.. _gofmt:
+  https://golang.org/cmd/gofmt/
+
+.. _Effective Go:
+  https://golang.org/doc/effective_go.html
+
+.. _Go Code Review Comments:
+  https://code.google.com/p/go-wiki/wiki/CodeReviewComments
+
 Mechanical Source Issues
 ========================
 
 Source Code Formatting
 ----------------------
 
 Commenting
 ^^^^^^^^^^