Home | History | Annotate | Download | only in doc
      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>
    638