Golang programming language specifications

Golang programming language specifications

I. Description

1. Programming specifications, and can avoid the trap of language, it may be advantageous teamwork, favorable project maintenance.
2. Go normal programming specifications, there are two: the compiler forces (necessary), gofmt non-mandatory format (non-essential).
3. Go declare support hump nomenclature, underlined exclusion method.
4. Custom principles:

a. unified workspace, to avoid arbitrary directory and file name

b. canonical variate / structure / name of the method and interface

c. Specification Notes

d. Test Unit / Program efficiency recommendations

Two levels: (S) recommendation, (M) must be. The following are the details.

II. Organization Code

1. (M) a directory contains only one packet, splitting module submodule complex / subdirectory
2. (S) point to multiple internal project GOPATH If the working directory. The first project to open a workspace (ie, go get to the first default download directory)
3. (M) non-test file (* _test.go) prohibits the use, to simplify the package
4. (M) introduced into the package inhibits relative path
5. (S) or IDE management recommendation import goimports
6. (S) rep need item contains all the code dependencies on the vendor
7. (S) recommended Golide, Godep manage third-party packages

In short: organizational structure needs to be simplified, at a glance, to allow a plurality of work sections, but the first working section must be open environment variable items, preferable to use a workspace, not relative path setup packets, preferably with other dependent godep library control tools to manage dependencies, all dependencies for each project the best placed in the catalog vendor.

III. Coding style

1. gofmt formatting code, (two tools which automatically defaults used when in IDE) golint check the code (M) when submitted Code
2. (S) json string recommended use single quote ( ')
3. (M) file name must be lowercase, allow underscore '_', but not the head and tail. _Test.go or avoid conflicts and other system-related _386.go
4. (S) to function as a guide file name, module name does not need to appear
5. (M) directory name must be lowercase, allowing underlined '-', but not head and tail
6. (S) is not recommended directory name appears underscore '_'
7. (M) package name must be all lowercase, no underlining, as short as possible, try not to duplicate names and standard library, prohibited by connecting multiple words underlined
8. (S) as far as possible consistent with the package name directory name
9. (M) the function name and the name of the structure must be the case hump mode, preferably without special characters such as scribing
10. (S) function name suggestions verb or verb-object structure of words, the structure is recommended noun or gerund
11. (S) constants and enumerations name, hump case law does not allow an underscore, third-party packages exception.
12. (M) the first letter lowercase function parameters can not be underlined, according to the size of the hump method
13. (S) function parameters according to the tightness of the arrangement position, the same type of parameters should be adjacent
14. (S) parameter not greater than 5
15. (M) does not allow underscore variable names, case law hump, local variables, the first letter lowercase, uppercase first letter of a global variable
16. (S) is often used to avoid a global variable, for single letter cycle may
17. (M) Interface name case law hump, first letter capitalized, can not underline, noun
18. 'Er' end (S) interface name
19. (M) complex functions like him to write a comment notes, annotation expression to be clear, not long-winded. Note standard temporarily forced, preferably godoc reference, such as the use of the package comment / * /, initials, a blank line after the comment, the comment written in the above functions and other functions.

All in all, the file name and directory name, package name must be lowercase. And other types of data and parameters define the variables CamelCase method is preferably used, do not use underlined or underlined

IV. Test Unit / Program efficiency

1. (S) recommended less use of main method to test, but the use of _test.go do the test
2. (M) with other languages ​​similar, if or avoid a step for embedded use, simple code required level, about less cerebral level
3. (M) named sucker avoid such IsTrue variables, if (! IsTrue).
4. (M) Familiarize yourself with the various features of the Go language, avoiding inefficient usage. Please read at least once:

yum -y install docker-io
# 拉镜像
docker pull hunterhug/gotourzh

# 前台运行
docker run -it -p 9999:9999 hunterhug/gotourzh

# 后台运行(类似nohup)
docker run -d -p 9999:9999 hunterhug/gotourzh
打开http://127.0.0.1:9999即可!

V. Some examples

package main

import "fmt"

func main() {
  buffedChan := make(chan int, 2)
  buffedChan <- 2
  buffedChan <- 3
  close(buffedChan) // 关闭后才能for打印出，否则死锁
  //close(buffedChan) // 不能重复关闭
  //buffedChan <- 4  // 关闭后就不能再送数据了，但是之前的数据还在
  for i := range buffedChan { // 必须关闭，否则死锁
    fmt.Println(i)
  }

  buffedChan1 := make(chan int, 2)
  buffedChan1 <- 2
  buffedChan1 <- 3
  j, ok := <-buffedChan1
  fmt.Println(j, ok)
  j, ok = <-buffedChan1
  fmt.Println(j, ok)

  close(buffedChan1)    // 关闭后才能，否则死锁
  j, ok = <-buffedChan1 // 如果未关闭，否则堵塞后死锁
  fmt.Println(j, ok)

  select {
  case j, ok := <-buffedChan1:
    fmt.Println("jjj", j, ok)
  default:
    fmt.Println("will not out")
  }
}