go packages which are fine
Go to file
2018-07-19 18:19:26 +00:00
jstream mtest->mrand: move rand functionality from mtest into its own package 2018-07-03 00:20:00 +00:00
m m: implement Log, have mdb.PubSub and mhttp.CfgServer use it, though I'm still not quite happy with it yet 2018-05-28 08:00:31 +00:00
mcfg mtest->mrand: move rand functionality from mtest into its own package 2018-07-03 00:20:00 +00:00
mcrypto mtest->mrand: move rand functionality from mtest into its own package 2018-07-03 00:20:00 +00:00
mdb mdb: break each inner database into its own package 2018-07-19 17:43:18 +00:00
mhttp m: implement Log, have mdb.PubSub and mhttp.CfgServer use it, though I'm still not quite happy with it yet 2018-05-28 08:00:31 +00:00
mlog mlog: refactor tests to use massert 2018-07-19 18:19:26 +00:00
mrand mtest->mrand: move rand functionality from mtest into its own package 2018-07-03 00:20:00 +00:00
mrpc mtest->mrand: move rand functionality from mtest into its own package 2018-07-03 00:20:00 +00:00
mtest mtest: implement Nil 2018-07-19 18:04:08 +00:00
mtime mtime: fix older package doc not having been deleted 2018-05-27 07:57:23 +00:00
env.test implement mdb.PubSub 2018-02-15 22:47:18 +00:00
LICENSE Initial commit 2018-01-11 15:47:01 +00:00
README.md README: add styleguide section 2018-03-26 10:54:01 +00:00

mediocre-go-lib

This is a collection of packages which I use across many of my personal projects. All packages intended to be used start with an m, packages not starting with m are for internal use within this set of packages.

Other third-party packages which integrate into these:

  • merry: used by mlog to embed KV logging information into error instances, it should be assumed that all errors returned from these packages are merry.Error instances. In cases where a package has a specific error it might return and which might be checked for a function to perform that equality check will be supplied as part of the package.

Styleguide

Here are general guidelines I use when making decisions about how code in this repo should be written. Most of the guidelines I have come up with myself have to do with package design, since packages are the only thing which have any rigidity and therefore need any rigid rules.

Everything here are guidelines, not actual rules.