github.com/kaituanwang/hyperledger@v2.0.1+incompatible/docs/source/style-guides/go-style.rst (about)

     1  Coding guidelines
     2  -----------------
     3  
     4  Coding Golang
     5  ~~~~~~~~~~~~~~
     6  
     7  We code in Go™ and try to follow the best practices and style outlined in
     8  `Effective Go <https://golang.org/doc/effective_go.html>`__ and the
     9  supplemental rules from the `Go Code Review Comments wiki
    10  <https://github.com/golang/go/wiki/CodeReviewComments>`__.
    11  
    12  We also recommend new contributors review the following before submitting
    13  pull requests:
    14  
    15    - `Practical Go <https://dave.cheney.net/practical-go/presentations/qcon-china.html>`__
    16    - `Go Proverbs <https://go-proverbs.github.io/>`__
    17  
    18  The following tools are executed against all pull requests. Any errors flagged
    19  by these tools must be addressed before the code will be merged:
    20  
    21    - `gofmt -s <https://golang.org/cmd/gofmt/>`__
    22    - `goimports <https://godoc.org/golang.org/x/tools/cmd/goimports>`__
    23    - `go vet <https://golang.org/cmd/vet/>`__
    24  
    25  Testing
    26  ^^^^^^^
    27  
    28  Unit tests are expected to accompany all production code changes. These tests
    29  should be fast, provide very good coverage for new and modified code, and
    30  support parallel execution.
    31  
    32  Two matching libraries are commonly used in our tests. When modifying code,
    33  please use the matching library that has already been chosen for the package.
    34  
    35    - `gomega <https://onsi.github.io/gomega/>`__
    36    - `testify/assert <https://godoc.org/github.com/stretchr/testify/assert>`__
    37  
    38  Any fixtures or data required by tests should generated or placed under version
    39  control. When fixtures are generated, they must be placed in a temporary
    40  directory created by ``ioutil.TempDir`` and cleaned up when the test
    41  terminates. When fixtures are placed under version control, they should be
    42  created inside a ``testdata`` folder; documentation that describes how to
    43  regenerate the fixtures should be provided in the tests or a ``README.txt``.
    44  Sharing fixtures across packages is strongly discouraged.
    45  
    46  When fakes or mocks are needed, they must be generated. Bespoke, hand-coded
    47  mocks are a maintenance burden and tend to include simulations that inevitably
    48  diverge from reality. Within Fabric, we use ``go generate`` directives to
    49  manage the generation with the following tools:
    50  
    51    - `counterfeiter <https://github.com/maxbrunsfeld/counterfeiter>`__
    52    - `mockery <https://github.com/vektra/mockery>`__
    53  
    54  API Documentation
    55  ^^^^^^^^^^^^^^^^^
    56  
    57  The API documentation for Hyperledger Fabric's Golang APIs is available
    58  in `GoDoc <https://godoc.org/github.com/hyperledger/fabric>`_.
    59  
    60  
    61  Generating gRPC code
    62  ---------------------
    63  
    64  If you modify any ``.proto`` files, run the following command to
    65  generate/update the respective ``.pb.go`` files.
    66  
    67  ::
    68  
    69      cd $GOPATH/src/github.com/hyperledger/fabric
    70      make protos
    71  
    72  Adding or updating Go packages
    73  ------------------------------
    74  
    75  Hyperledger Fabric vendors dependencies. This means that all required packages
    76  reside in the ``$GOPATH/src/github.com/hyperledger/fabric/vendor`` folder. Go
    77  will use packages in this folder instead of the GOPATH when the ``go install``
    78  or ``go build`` commands are executed. To manage the packages in the ``vendor``
    79  folder, we use `dep <https://golang.github.io/dep/>`__.
    80  
    81  .. Licensed under Creative Commons Attribution 4.0 International License
    82     https://creativecommons.org/licenses/by/4.0/