From d2acef50faefe3f127e2ff699bbfff65855c825c Mon Sep 17 00:00:00 2001 From: Erik Winter Date: Wed, 23 Feb 2022 20:50:31 +0100 Subject: [PATCH] text edit --- doc/logging-in-golang.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/logging-in-golang.adoc b/doc/logging-in-golang.adoc index a6df78b..2745d73 100644 --- a/doc/logging-in-golang.adoc +++ b/doc/logging-in-golang.adoc @@ -1,4 +1,4 @@ -= My Take on logging in go += My take on logging in go Erik Winter 2021-04-08 @@ -141,7 +141,7 @@ Here `log.DefaultTimestampUTC` and `log.DefaultCaller` are functions. With a log As can be seen in the examples above, when building context it helps to treat a logger as an instance of type Logger and use it it to create new instances, instead of relying on a single logger that is globally present. A natural consequence of this is that a logger should be a parameter that is passed around whenever necessary. At first sight it seems cumbersome and verbose to do that everywhere in your code. -However, it is not necessary to pass the logger to every part of the code, since not every part of the code has the need to log. If we examine a https://erikwinter.nl/notes/2021/my-default-golang-directory-structure/[basic directory structure for Go projects] and look what kind of packages each folder holds: +However, it is not necessary to pass the logger to every part of the code, since not every part of the code has the need to log. If we examine a https://ewintr.nl/devnotes/2021/depend-less-on-dependencies-with-the-adapter-pattern-in-go/[basic directory structure for Go projects] and look what kind of packages each folder holds: ---- .