29

Naming conventions for go packages are well-documented, with golang.org's blog stating:

Good package names are short and clear. They are lower case, with no under_scores or mixedCaps. They are often simple nouns, such as [descriptions removed]: time, list, http

The same guide then presents two examples of bad names:

Here are two examples of names that might be good style in other languages but do not fit well in Go: computeServiceClient, priority_queue

What the guide doesn't say is what to do when you have a package with a very specific purpose that really doesn't fit well as a one-word noun.

We have a library called Rhino Horn used internally for finding credentials that are being leaked accidentally. For reasons owing to how resource intensive it is to run Rhino Horn, I've been instructed to write a supervisor in golang for Rhino Horn that monitors its performance and enables quick shutoff when needed. Rhino Horn wasn't written in go, and is an entirely separate project.

What would the golang naming conventions have me name the Rhino Horn Supervisor?

TheEnvironmentalist
  • 2,694
  • 2
  • 19
  • 46
  • 2
    I would probably use package names of `rhinohorn` and/or `supervisor`. Or maybe a type named `Supervisor` inside package `rhinohorn`. Do you actually need to refer to Rhino Horn in the structure of the code? Maybe the application can just monitor stuff and be configured to monitor Rhino Horn, though I realize that may not be easily done depending on the reality of your actual deployment. – Thomas Jun 13 '18 at 17:02
  • 2
    I think you should just use rhino_horn_supervisor. Write code whatever you want ,do not let some stupid guideline limit your thought. MixedCaps may have bug with os that filename is case insensitive. I think you should avoid upper case letter in filename. – bronze man Oct 23 '19 at 07:11

1 Answers1

11

I think there are many many many options. A few of which are:

  • If your project is only focused on supervising rhino horn you could name your project rhino-horn-supervisor and not package anything just have flat top level files main.go, hornoutput.go, or w/e
  • If supervising rhino horn is one component of a larger application there could be lots of setups, one of which could be a supervisors package and rhino horn being a single file with its implementation
  • Theres also the possibility of sub packages, supervisors/rhinohorn package
  • Also you could just make a rhinohorn package with a supervisor.go file :P
dm03514
  • 54,664
  • 18
  • 108
  • 145