-
Remember LESS is MORE.
-
readability
= not hiding the cost;simplicity
= hide complexity -
If you don't UNDERSTAND the
DATA
, you DON'T UNDERSTAND the PROBLEM you're working on. -
Remember:
stack
(stay on stack) vsheap
(share on heap) -
Take command of
type
& Take command ofsemantics
-
Mantra: REDUCE, MINIMIZE, SIMPLIFY.
-
Never share a string or slice
unless
you're marshaling or unmarshaling. -
Small is fast = because smaller data structures can stay within the cachelines.
-
Memory leak in go: a reference on the heap that
isn't garbage collected
ANDnot being used
. -
It's never a good reason to alter a data set after you pull it!
-
Know your length when getting a slice of a slice.
-
(Big NO NO) Don't mix
value semantics
WITHpointer semantics
; vice versa. -
When in doubt USE
pointer semantics
; except with time. -
Method sets dictate interface compliance.
-
We do not use embedding to reuse state! We use embedding to reuse behavior. (WE EMBED BECAUSE WE NEED BEHAVIOR)
-
Group by behavior (by things that they do vs. what they are).
-
There is implicit conversion in go with interface types because they are valueless and same memory model.
-
Always
return
theerror
interface type -
Don't use
pointer semantics
when dealing witherror
handling, because the addresses are always different. -
You are not allowed to both: log an
error
&& pass it up. -
You are not allowed to create a
go routine
unless you can determine WHEN and HOW it will be terminated -
Do not think of channels as queues, but as
signals
. -
Don't use a buffer larger than 1; Anything more and it's unsafe.
- Using
<=1
= somewhat of a garuntee. - Easier to catch problems/bugs.
- Using
derekahn / ultimate-go Goto Github PK
View Code? Open in Web Editor NEWArdanlabs Go training with Bill Kennedy.