Bomoko and other nonsense words

Here we go through the rest of Chapter 2  10 - Not being aware of the possible problems with type embedding Go allows you to not only include types as fields in structs, but also to embed them. Essentially this makes the fields of the embedded/base type part of the "containers" interface. Harsanyi points out that this can lead to exposing more than you might want to, since all of the base type's fields and behaviors are exposed as part of the container. If there is reason to hide the base struct's details, rather simply include it as an unexported field and write accessors. 11 - Not using the functional options pattern I'll admit that I hadn't heard about, or consciously noticed, this pattern before now, but it's quite brilliant. An issue with positional arguments in complex functions is that having tons of arguments that are either null, or unused along certain paths, etc. is a real PITA. My own preference, when factoring out the functionality into mult

So I'm pretty much looking for a place to write up notes on things I'm reading - which, right now, includes Teiva Harsanyi's "100 Go Mistakes and How to Avoid Them" (does anyone else get confused when writing title-case? Let me look up the rules quick ).   Anyway, I'm at a point where I want to write down some of what I'm learning so I can refer back to it later, so let's go. 1 - Unintended variable shadowing Go's short variable declaration operator (:=) can introduce unintended effects if you're making use of it within nested blocks. Here's a simple example . The workaround is really to explicitly assign the value to the variable declared in the outer scope, either by using temporary variables when using the declaration operator, or simply assigning directly. 2 - Unnecessary nested code This provides a fairly useful heuristic with regards to code complexity. Essentially, Harsanyi wants us to try, as far as possible, to keep the "happ