When building a command-line tool in Go, you’ll eventually want to accept arguments as flags.

If you’re using the standard library’s flag package, you’ll have to decide where in your package to define your flags. The only requirement of flag is that the flags be defined before flag.Parse() is called.

After reviewing many existing packages, the most common way to define command-line flags can be demonstrated with this small program:

package main

import (
    "flag"
    "net/http"
)

var (
    httpAddr = flag.String("http", ":5050", "HTTP service address")
)

func main() {
    flag.Parse()
    serve()
}

func serve() {
    http.ListenAndServe(*httpAddr, nil)
}

This style defines flags as package variables, parses them at the start of main, and dereferences their values as necessary within the package’s functions.

But this is not the only way to set up your package’s flags. Consider the following alternative of the program above:

func main() {
    var (
        httpAddr = flag.String("http", ":5050", "HTTP service address")
    )
    flag.Parse()

    serve(*httpAddr)
}

func serve(addr string) {
    http.ListenAndServe(addr, nil)
}

In the second version, we’ve moved our flag declaration into the main function. This is better, because the flag now lives next to where the flags are parsed.

We also needed to update our serve function to accept the the address to listen on as a parameter. This is great, because serve no longer depends on package state, but instead declares all of its dependencies. Previously, if we wanted to test serve, we would need to set the flag’s value before each test case, and be careful to reset its value afterward. For this reason, we also would not have been able to run our tests concurrently. Now each test case can provide its own value as input to the function, without worrying about contention or contamination.

Finally, it’s a nice bonus that we were able to dereference the flag value before calling serve. Dealing with pointers to builtin types like string, int, or float is cumbersome, and often a smell since they can be nil, or accidentally be modified in unsafe ways.

Now, this doesn’t make a huge difference in our small example, but if you approach all your main methods like this, you’ll arrive at a better (and more testable!) design, because it forces you to deal explicitly with dependencies, instead of being able to fall back on external state.