Using Singular Form for Collection Repo/Folder Name in Idiomatic Go

Dimas Maulana Development

10-02-2022

Contents

In the world of Go programming, adhering to idiomatic coding practices is highly valued. One of these practices pertains to the naming of collection repository or folder names. The Go community recommends using the singular form for such names, and this convention is followed consistently in various Go projects. Let’s take a closer look at this best practice.

Singular vs. Plural

When organizing your Go packages into repositories or folders, you’ll often find situations where you have multiple related packages that belong to a common category. Examples could include packages for various utilities, components, or modules. In such cases, it’s recommended to use the singular form for the repository or folder name.

Examples of Using Singular Form

Here are some examples of Go repositories or folders using the singular form:

In these examples, you can see that the folder names like “example,” “image,” and “player” use the singular form despite containing multiple related packages. This consistency in naming makes it easier for developers to navigate and understand the project’s structure.

Avoiding Plural Forms

To maintain this naming convention, it’s essential to avoid using plural forms for collection repository or folder names. Here are some examples of what not to do:

In these cases, you can observe the use of plural forms for folder names, which goes against the recommended Go idiomatic style.

Consistency Matters

The use of singular forms for collection repository or folder names is not just a matter of convention; it’s also about maintaining consistency within the Go ecosystem. By adhering to this practice, you not only make your codebase more approachable but also align with the style that the Go project itself follows.

In summary, when organizing your Go packages into repositories or folders, consider using the singular form for collection names. This practice promotes clarity, consistency, and adherence to the idiomatic Go style, making your code more accessible to other developers and contributing to the overall Go community’s best practices.