When writing a single package meant to be used as a command, which is idiomatic: name all identifiers as private or name all identifiers as public?

Question

In Go, public names start with an upper case letter and private names start with a lower case letter.

I'm writing a program that is not library and is a single package. Is there any Go idiom that stipulates whether my identifiers should be all public or all private? I do not plan on using this package as a library or as something that should be imported from another Go program.

I can't think of any reason why I'd want a mixture. It "feels" like going all private is the proper choice.

---

I don't think I got any concrete answer, but Nate was closest with telling me to think of "exporting vs non-exporting" instead of "public and private".

This leads me to believe that not exporting anything is the best approach. In the worst case scenario, if I end up importing code from my application in another package, I will have to rethink what should be exported and what shouldn't be. Which is a good thing IMO.

Answer 1

In the described situation both approaches are equally valid, so it's more or less a matter of personal preferences. In my case I'm using camelCase identifiers for package main, mostly out of habit.

Answer 2

If you are attempting to adjust your mindset to be more Go idiomatic, you should stop thinking of variables, functions, and methods as public or private. The more accurate term is exported or not exported. It definitely has a more C like feel to it.

As others have stated exporting really isn't needed for application program code. If for organizational reasons you decide to break your program up into packages, you could use sub-packages. At work we've decided to do just this. We have:

projectgopath/src/projectname
                  projectname/subcomponent1
                  projectname/subcomponent2

So far I am really liking this structure. It aids in separation of concerns, but does not go to the extent of making a package outside of the main project. The intent is clear. The sub-package's intended use is for this program only...

The new go build and go install commands seem to deal very well with it. We group components together in packages and expose only the necessary bits via exports.