aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--content/organizing-go-code.article2
1 files changed, 1 insertions, 1 deletions
diff --git a/content/organizing-go-code.article b/content/organizing-go-code.article
index 185034f..17e8831 100644
--- a/content/organizing-go-code.article
+++ b/content/organizing-go-code.article
@@ -46,7 +46,7 @@ On the other hand, it is also easy to go overboard in splitting your code into s
Look to the Go standard libraries as a guide. Some of its packages are large and some are small. For instance, the [[http://golang.org/pkg/net/http/][http package]] comprises 17 go source files (excluding tests) and exports 109 identifiers, and the [[http://golang.org/pkg/hash/][hash package]] consists of one file that exports just three declarations. There is no hard and fast rule; both approaches are appropriate given their context.
-With that said, package main is often larger than other packages. Complex commands contain a lot of code that is of little use outside the context of the executable, and often it's simpler to just keep it all in the one place. Godoc is nearly 6000 lines over [[http://golang.org/src/cmd/godoc/][16 files]], and the go tool is more than 7000 lines spread across [[http://golang.org/src/cmd/go/][23 files]].
+With that said, package main is often larger than other packages. Complex commands contain a lot of code that is of little use outside the context of the executable, and often it's simpler to just keep it all in the one place. For instance, the go tool is more than 12000 lines spread across [[http://golang.org/src/cmd/go/][34 files]].
* Document your code