github.com/zach-klippenstein/go@v0.0.0-20150108044943-fcfbeb3adf58/doc/code.html (about)

     1  <!--{
     2  	"Title": "How to Write Go Code"
     3  }-->
     4  
     5  <h2 id="Introduction">Introduction</h2>
     6  
     7  <p>
     8  This document demonstrates the development of a simple Go package and
     9  introduces the <a href="/cmd/go/">go tool</a>, the standard way to fetch,
    10  build, and install Go packages and commands.
    11  </p>
    12  
    13  <p>
    14  The <code>go</code> tool requires you to organize your code in a specific
    15  way. Please read this document carefully.
    16  It explains the simplest way to get up and running with your Go installation.
    17  </p>
    18  
    19  <p>
    20  A similar explanation is available as a
    21  <a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
    22  </p>
    23  
    24  
    25  <h2 id="Organization">Code organization</h2>
    26  
    27  <h3 id="Workspaces">Workspaces</h3>
    28  
    29  <p>
    30  The <code>go</code> tool is designed to work with open source code maintained
    31  in public repositories. Although you don't need to publish your code, the model
    32  for how the environment is set up works the same whether you do or not.
    33  </p>
    34  
    35  <p>
    36  Go code must be kept inside a <i>workspace</i>.
    37  A workspace is a directory hierarchy with three directories at its root:
    38  </p>
    39  
    40  <ul>
    41  <li><code>src</code> contains Go source files organized into packages (one package per directory),
    42  <li><code>pkg</code> contains package objects, and
    43  <li><code>bin</code> contains executable commands.
    44  </ul>
    45  
    46  <p>
    47  The <code>go</code> tool builds source packages and installs the resulting
    48  binaries to the <code>pkg</code> and <code>bin</code> directories.
    49  </p>
    50  
    51  <p>
    52  The <code>src</code> subdirectory typically contains multiple version control
    53  repositories (such as for Git or Mercurial) that track the development of one
    54  or more source packages.
    55  </p>
    56  
    57  <p>
    58  To give you an idea of how a workspace looks in practice, here's an example:
    59  </p>
    60  
    61  <pre>
    62  bin/
    63      hello                          # command executable
    64      outyet                         # command executable
    65  pkg/
    66      linux_amd64/
    67          github.com/golang/example/
    68              stringutil.a           # package object
    69  src/
    70      <a href="https://github.com/golang/example/">github.com/golang/example/</a>
    71          .git/                      # Git repository metadata
    72  	hello/
    73  	    hello.go               # command source
    74  	outyet/
    75  	    main.go                # command source
    76  	    main_test.go           # test source
    77  	stringutil/
    78  	    reverse.go             # package source
    79  	    reverse_test.go        # test source
    80  </pre>
    81  
    82  <p>
    83  This workspace contains one repository (<code>example</code>)
    84  comprising two commands (<code>hello</code> and <code>outyet</code>)
    85  and one library (<code>stringutil</code>).
    86  </p>
    87  
    88  <p>
    89  A typical workspace would contain many source repositories containing many
    90  packages and commands. Most Go programmers keep <i>all</i> their Go source code
    91  and dependencies in a single workspace.
    92  </p>
    93  
    94  <p>
    95  Commands and libraries are built from different kinds of source packages.
    96  We will discuss the distinction <a href="#PackageNames">later</a>.
    97  </p>
    98  
    99  
   100  <h3 id="GOPATH">The <code>GOPATH</code> environment variable</h3>
   101  
   102  <p>
   103  The <code>GOPATH</code> environment variable specifies the location of your
   104  workspace. It is likely the only environment variable you'll need to set
   105  when developing Go code.
   106  </p>
   107  
   108  <p>
   109  To get started, create a workspace directory and set <code>GOPATH</code>
   110  accordingly. Your workspace can be located wherever you like, but we'll use
   111  <code>$HOME/work</code> in this document. Note that this must <b>not</b> be the
   112  same path as your Go installation.
   113  (Another common setup is to set <code>GOPATH=$HOME</code>.)
   114  </p>
   115  
   116  <pre>
   117  $ <b>mkdir $HOME/work</b>
   118  $ <b>export GOPATH=$HOME/work</b>
   119  </pre>
   120  
   121  <p>
   122  For convenience, add the workspace's <code>bin</code> subdirectory
   123  to your <code>PATH</code>:
   124  </p>
   125  
   126  <pre>
   127  $ <b>export PATH=$PATH:$GOPATH/bin</b>
   128  </pre>
   129  
   130  <p>
   131  To learn more about setting up the <code>GOPATH</code> environment variable,
   132  please see
   133  <a href="/cmd/go/#hdr-GOPATH_environment_variable"><code>go help gopath</code></a>
   134  </p>
   135  
   136  <h3 id="PackagePaths">Package paths</h3>
   137  
   138  <p>
   139  The packages from the standard library are given short paths such as
   140  <code>"fmt"</code> and <code>"net/http"</code>.
   141  For your own packages, you must choose a base path that is unlikely to
   142  collide with future additions to the standard library or other external
   143  libraries.
   144  </p>
   145  
   146  <p>
   147  If you keep your code in a source repository somewhere, then you should use the
   148  root of that source repository as your base path.
   149  For instance, if you have a <a href="https://github.com/">GitHub</a> account at
   150  <code>github.com/user</code>, that should be your base path.
   151  </p>
   152  
   153  <p>
   154  Note that you don't need to publish your code to a remote repository before you
   155  can build it. It's just a good habit to organize your code as if you will
   156  publish it someday. In practice you can choose any arbitrary path name,
   157  as long as it is unique to the standard library and greater Go ecosystem.
   158  </p>
   159  
   160  <p>
   161  We'll use <code>github.com/user</code> as our base path. Create a directory
   162  inside your workspace in which to keep source code:
   163  </p>
   164  
   165  <pre>
   166  $ <b>mkdir -p $GOPATH/src/github.com/user</b>
   167  </pre>
   168  
   169  
   170  <h3 id="Command">Your first program</h3>
   171  
   172  <p>
   173  To compile and run a simple program, first choose a package path (we'll use
   174  <code>github.com/user/hello</code>) and create a corresponding package directory
   175  inside your workspace:
   176  </p>
   177  
   178  <pre>
   179  $ <b>mkdir $GOPATH/src/github.com/user/hello</b>
   180  </pre>
   181  
   182  <p>
   183  Next, create a file named <code>hello.go</code> inside that directory,
   184  containing the following Go code.
   185  </p>
   186  
   187  <pre>
   188  package main
   189  
   190  import "fmt"
   191  
   192  func main() {
   193  	fmt.Printf("Hello, world.\n")
   194  }
   195  </pre>
   196  
   197  <p>
   198  Now you can build and install that program with the <code>go</code> tool:
   199  </p>
   200  
   201  <pre>
   202  $ <b>go install github.com/user/hello</b>
   203  </pre>
   204  
   205  <p>
   206  Note that you can run this command from anywhere on your system. The
   207  <code>go</code> tool finds the source code by looking for the
   208  <code>github.com/user/hello</code> package inside the workspace specified by
   209  <code>GOPATH</code>.
   210  </p>
   211  
   212  <p>
   213  You can also omit the package path if you run <code>go install</code> from the
   214  package directory:
   215  </p>
   216  
   217  <pre>
   218  $ <b>cd $GOPATH/src/github.com/user/hello</b>
   219  $ <b>go install</b>
   220  </pre>
   221  
   222  <p>
   223  This command builds the <code>hello</code> command, producing an executable
   224  binary. It then installs that binary to the workspace's <code>bin</code>
   225  directory as <code>hello</code> (or, under Windows, <code>hello.exe</code>).
   226  In our example, that will be <code>$GOPATH/bin/hello</code>, which is
   227  <code>$HOME/work/bin/hello</code>.
   228  </p>
   229  
   230  <p>
   231  The <code>go</code> tool will only print output when an error occurs, so if
   232  these commands produce no output they have executed successfully.
   233  </p>
   234  
   235  <p>
   236  You can now run the program by typing its full path at the command line:
   237  </p>
   238  
   239  <pre>
   240  $ <b>$GOPATH/bin/hello</b>
   241  Hello, world.
   242  </pre>
   243  
   244  <p>
   245  Or, as you have added <code>$GOPATH/bin</code> to your <code>PATH</code>,
   246  just type the binary name:
   247  </p>
   248  
   249  <pre>
   250  $ <b>hello</b>
   251  Hello, world.
   252  </pre>
   253  
   254  <p>
   255  If you're using a source control system, now would be a good time to initialize
   256  a repository, add the files, and commit your first change. Again, this step is
   257  optional: you do not need to use source control to write Go code.
   258  </p>
   259  
   260  <pre>
   261  $ <b>cd $GOPATH/src/github.com/user/hello</b>
   262  $ <b>git init</b>
   263  Initialized empty Git repository in /home/user/work/src/github.com/user/hello/.git/
   264  $ <b>git add hello.go</b>
   265  $ <b>git commit -m "initial commit"</b>
   266  [master (root-commit) 0b4507d] initial commit
   267   1 file changed, 1 insertion(+)
   268    create mode 100644 hello.go
   269  </pre>
   270  
   271  <p>
   272  Pushing the code to a remote repository is left as an exercise for the reader.
   273  </p>
   274  
   275  
   276  <h3 id="Library">Your first library</h3>
   277  
   278  <p>
   279  Let's write a library and use it from the <code>hello</code> program.
   280  </p>
   281  
   282  <p>
   283  Again, the first step is to choose a package path (we'll use
   284  <code>github.com/user/stringutil</code>) and create the package directory:
   285  </p>
   286  
   287  <pre>
   288  $ <b>mkdir $GOPATH/src/github.com/user/stringutil</b>
   289  </pre>
   290  
   291  <p>
   292  Next, create a file named <code>reverse.go</code> in that directory with the
   293  following contents.
   294  </p>
   295  
   296  <pre>
   297  // Package stringutil contains utility functions for working with strings.
   298  package stringutil
   299  
   300  // Reverse returns its argument string reversed rune-wise left to right.
   301  func Reverse(s string) string {
   302  	r := []rune(s)
   303  	for i, j := 0, len(r)-1; i &lt; len(r)/2; i, j = i+1, j-1 {
   304  		r[i], r[j] = r[j], r[i]
   305  	}
   306  	return string(r)
   307  }
   308  </pre>
   309  
   310  <p>
   311  Now, test that the package compiles with <code>go build</code>:
   312  </p>
   313  
   314  <pre>
   315  $ <b>go build github.com/user/stringutil</b>
   316  </pre>
   317  
   318  <p>
   319  Or, if you are working in the package's source directory, just:
   320  </p>
   321  
   322  <pre>
   323  $ <b>go build</b>
   324  </pre>
   325  
   326  <p>
   327  This won't produce an output file. To do that, you must use <code>go
   328  install</code>, which places the package object inside the <code>pkg</code>
   329  directory of the workspace.
   330  </p>
   331  
   332  <p>
   333  After confirming that the <code>stringutil</code> package builds,
   334  modify your original <code>hello.go</code> (which is in
   335  <code>$GOPATH/src/github.com/user/hello</code>) to use it:
   336  </p>
   337  
   338  <pre>
   339  package main
   340  
   341  import (
   342  	"fmt"
   343  
   344  	<b>"github.com/user/stringutil"</b>
   345  )
   346  
   347  func main() {
   348  	fmt.Printf(stringutil.Reverse("!oG ,olleH"))
   349  }
   350  </pre>
   351  
   352  <p>
   353  Whenever the <code>go</code> tool installs a package or binary, it also
   354  installs whatever dependencies it has.
   355  So when you install the <code>hello</code> program
   356  </p>
   357  
   358  <pre>
   359  $ <b>go install github.com/user/hello</b>
   360  </pre>
   361  
   362  <p>
   363  the <code>stringutil</code> package will be installed as well, automatically.
   364  </p>
   365  
   366  <p>
   367  Running the new version of the program, you should see a new, reversed message:
   368  </p>
   369  
   370  <pre>
   371  $ <b>hello</b>
   372  Hello, Go!
   373  </pre>
   374  
   375  <p>
   376  After the steps above, your workspace should look like this:
   377  </p>
   378  
   379  <pre>
   380  bin/
   381      hello                 # command executable
   382  pkg/
   383      linux_amd64/          # this will reflect your OS and architecture
   384          github.com/user/
   385              stringutil.a  # package object
   386  src/
   387      github.com/user/
   388          hello/
   389              hello.go      # command source
   390          stringutil/
   391              reverse.go    # package source
   392  </pre>
   393  
   394  <p>
   395  Note that <code>go install</code> placed the <code>stringutil.a</code> object
   396  in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
   397  directory.
   398  This is so that future invocations of the <code>go</code> tool can find the
   399  package object and avoid recompiling the package unnecessarily.
   400  The <code>linux_amd64</code> part is there to aid in cross-compilation,
   401  and will reflect the operating system and architecture of your system.
   402  </p>
   403  
   404  <p>
   405  Go command executables are statically linked; the package objects need not
   406  be present to run Go programs.
   407  </p>
   408  
   409  
   410  <h3 id="PackageNames">Package names</h3>
   411  
   412  <p>
   413  The first statement in a Go source file must be
   414  </p>
   415  
   416  <pre>
   417  package <i>name</i>
   418  </pre>
   419  
   420  <p>
   421  where <code><i>name</i></code> is the package's default name for imports.
   422  (All files in a package must use the same <code><i>name</i></code>.)
   423  </p>
   424  
   425  <p>
   426  Go's convention is that the package name is the last element of the
   427  import path: the package imported as "<code>crypto/rot13</code>"
   428  should be named <code>rot13</code>.
   429  </p>
   430  
   431  <p>
   432  Executable commands must always use <code>package main</code>.
   433  </p>
   434  
   435  <p>
   436  There is no requirement that package names be unique
   437  across all packages linked into a single binary,
   438  only that the import paths (their full file names) be unique.
   439  </p>
   440  
   441  <p>
   442  See <a href="/doc/effective_go.html#names">Effective Go</a> to learn more about
   443  Go's naming conventions.
   444  </p>
   445  
   446  
   447  <h2 id="Testing">Testing</h2>
   448  
   449  <p>
   450  Go has a lightweight test framework composed of the <code>go test</code>
   451  command and the <code>testing</code> package.
   452  </p>
   453  
   454  <p>
   455  You write a test by creating a file with a name ending in <code>_test.go</code>
   456  that contains functions named <code>TestXXX</code> with signature
   457  <code>func (t *testing.T)</code>.
   458  The test framework runs each such function;
   459  if the function calls a failure function such as <code>t.Error</code> or
   460  <code>t.Fail</code>, the test is considered to have failed.
   461  </p>
   462  
   463  <p>
   464  Add a test to the <code>stringutil</code> package by creating the file
   465  <code>$GOPATH/src/github.com/user/stringutil/reverse_test.go</code> containing
   466  the following Go code.
   467  </p>
   468  
   469  <pre>
   470  package stringutil
   471  
   472  import "testing"
   473  
   474  func TestReverse(t *testing.T) {
   475  	cases := []struct {
   476  		in, want string
   477  	}{
   478  		{"Hello, world", "dlrow ,olleH"},
   479  		{"Hello, 世界", "界世 ,olleH"},
   480  		{"", ""},
   481  	}
   482  	for _, c := range cases {
   483  		got := Reverse(c.in)
   484  		if got != c.want {
   485  			t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want)
   486  		}
   487  	}
   488  }
   489  </pre>
   490  
   491  <p>
   492  Then run the test with <code>go test</code>:
   493  </p>
   494  
   495  <pre>
   496  $ <b>go test github.com/user/stringutil</b>
   497  ok  	github.com/user/stringutil 0.165s
   498  </pre>
   499  
   500  <p>
   501  As always, if you are running the <code>go</code> tool from the package
   502  directory, you can omit the package path:
   503  </p>
   504  
   505  <pre>
   506  $ <b>go test</b>
   507  ok  	github.com/user/stringutil 0.165s
   508  </pre>
   509  
   510  <p>
   511  Run <code><a href="/cmd/go/#hdr-Test_packages">go help test</a></code> and see the
   512  <a href="/pkg/testing/">testing package documentation</a> for more detail.
   513  </p>
   514  
   515  
   516  <h2 id="remote">Remote packages</h2>
   517  
   518  <p>
   519  An import path can describe how to obtain the package source code using a
   520  revision control system such as Git or Mercurial. The <code>go</code> tool uses
   521  this property to automatically fetch packages from remote repositories.
   522  For instance, the examples described in this document are also kept in a
   523  Git repository hosted at GitHub
   524  <code><a href="https://github.com/golang/example">github.com/golang/example</a></code>.
   525  If you include the repository URL in the package's import path,
   526  <code>go get</code> will fetch, build, and install it automatically:
   527  </p>
   528  
   529  <pre>
   530  $ <b>go get github.com/golang/example/hello</b>
   531  $ <b>$GOPATH/bin/hello</b>
   532  Hello, Go examples!
   533  </pre>
   534  
   535  <p>
   536  If the specified package is not present in a workspace, <code>go get</code>
   537  will place it inside the first workspace specified by <code>GOPATH</code>.
   538  (If the package does already exist, <code>go get</code> skips the remote
   539  fetch and behaves the same as <code>go install</code>.)
   540  </p>
   541  
   542  <p>
   543  After issuing the above <code>go get</code> command, the workspace directory
   544  tree should now look like this:
   545  </p>
   546  
   547  <pre>
   548  bin/
   549      hello                           # command executable
   550  pkg/
   551      linux_amd64/
   552          github.com/golang/example/
   553              stringutil.a            # package object
   554          github.com/user/
   555              stringutil.a            # package object
   556  src/
   557      github.com/golang/example/
   558  	.git/                       # Git repository metadata
   559          hello/
   560              hello.go                # command source
   561          stringutil/
   562              reverse.go              # package source
   563              reverse_test.go         # test source
   564      github.com/user/
   565          hello/
   566              hello.go                # command source
   567          stringutil/
   568              reverse.go              # package source
   569              reverse_test.go         # test source
   570  </pre>
   571  
   572  <p>
   573  The <code>hello</code> command hosted at GitHub depends on the
   574  <code>stringutil</code> package within the same repository. The imports in
   575  <code>hello.go</code> file use the same import path convention, so the
   576  <code>go get</code> command is able to locate and install the dependent
   577  package, too.
   578  </p>
   579  
   580  <pre>
   581  import "github.com/golang/example/stringutil"
   582  </pre>
   583  
   584  <p>
   585  This convention is the easiest way to make your Go packages available for
   586  others to use.
   587  The <a href="//golang.org/wiki/Projects">Go Wiki</a>
   588  and <a href="//godoc.org/">godoc.org</a>
   589  provide lists of external Go projects.
   590  </p>
   591  
   592  <p>
   593  For more information on using remote repositories with the <code>go</code> tool, see
   594  <code><a href="/cmd/go/#hdr-Remote_import_paths">go help importpath</a></code>.
   595  </p>
   596  
   597  
   598  <h2 id="next">What's next</h2>
   599  
   600  <p>
   601  Subscribe to the
   602  <a href="//groups.google.com/group/golang-announce">golang-announce</a>
   603  mailing list to be notified when a new stable version of Go is released.
   604  </p>
   605  
   606  <p>
   607  See <a href="/doc/effective_go.html">Effective Go</a> for tips on writing
   608  clear, idiomatic Go code.
   609  </p>
   610  
   611  <p>
   612  Take <a href="//tour.golang.org/">A Tour of Go</a> to learn the language
   613  proper.
   614  </p>
   615  
   616  <p>
   617  Visit the <a href="/doc/#articles">documentation page</a> for a set of in-depth
   618  articles about the Go language and its libraries and tools.
   619  </p>
   620  
   621  
   622  <h2 id="help">Getting help</h2>
   623  
   624  <p>
   625  For real-time help, ask the helpful gophers in <code>#go-nuts</code> on the
   626  <a href="http://freenode.net/">Freenode</a> IRC server.
   627  </p>
   628  
   629  <p>
   630  The official mailing list for discussion of the Go language is
   631  <a href="//groups.google.com/group/golang-nuts">Go Nuts</a>.
   632  </p>
   633  
   634  <p>
   635  Report bugs using the
   636  <a href="//golang.org/issue">Go issue tracker</a>.
   637  </p>