Code organization tips with packages hackernoon.com5 years ago in #Dev Love63

Originally published by Inanc Gumus on September 26th 2017 How to organize Go code with packages? Imagine a package like above: It packages like-minded source codes together. For small programs, you probably don’t need to define another package other than the special package: main. For bigger programs, you might need to define your own packages to organize your code. For people who work on the same code to create many programs, they may need to define their own libraries and import these to their own programs. In my own projects, I create a cmd folder to keep entry-point applications of my program, then I do dependency-injection and other orchestration code there. All of the other code lives inside internal folders and not get reused by the outer packages other than the ones in my program. Splitting packages into sub-directories You can split packages into subdirectories, Go stdlib uses this style. Look at http package for example. It’s inside net package. Http things belong to network things, so, they put it under net package. However, that doesn’t mean that, http package can use net package’s internals, it cannot. Each go package is a different beast on its own, there’s no relationship between net and http package in stdlib other than the organization purposes. Go provides no sub-packaging mechanism and when you split up your packages to organize your BIG package, you may make some of the internals of your package to the outside world, and so, anyone can import them. You may not want this, so, internal package convention prevents your packages to be imported from unwanted parties. I explain internal packages here in this post. And, last, new gophers who are beginning to Go, create, src/ folders, you don’t need to do that. Just put your source files into your project root. It’s better that way. Names should be as simple as possible like: http, zip, and time. You and other people are going to use and recall them with this name. Keep them short, simple, concise and to the point. Do not use double or more words in names like: net_http. Do it like: net/http. Different packages, but because http package is inside net directory, if there was another package which named also as http, there will be no problem, because they live in separate directories. Let the package path speaks for what the packages does. net/http. It’s clear, isn’t? http package is a package that does things related somehow with networking. If it was inside security/http package it’d imply different meanings. Use common abbrevations if it’s familiar to the programmers (or to the programmers in domain of the application you’re building). For example: Instead of formattedIO, stdlib uses fmt. Definitely avoid ultra-generic package names like api, models, common, utils, helper etc. For example: Instead of a model package, define a package that does user things named as user. Do not use underscores or camel-casing. Just use lowercase letters. Names can contain unicode characters (however I don’t recommend using this) More on this here and here.  » Read More

Like to keep reading?

This article first appeared on If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply