diff options
95 files changed, 449 insertions, 125 deletions
diff --git a/prompts/skills/100-go-mistakes/references/mistake-01-unintended-variable-shadowing.md b/prompts/skills/100-go-mistakes/references/mistake-01-unintended-variable-shadowing.md index 076039e..54d5f69 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-01-unintended-variable-shadowing.md +++ b/prompts/skills/100-go-mistakes/references/mistake-01-unintended-variable-shadowing.md @@ -1,7 +1,6 @@ # Mistake #1: Unintended variable shadowing #### TL;DR -TL;DR Avoiding shadowed variables can help prevent mistakes like referencing the wrong variable or confusing readers. diff --git a/prompts/skills/100-go-mistakes/references/mistake-02-unnecessary-nested-code.md b/prompts/skills/100-go-mistakes/references/mistake-02-unnecessary-nested-code.md index dfd04f3..e8cf6c4 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-02-unnecessary-nested-code.md +++ b/prompts/skills/100-go-mistakes/references/mistake-02-unnecessary-nested-code.md @@ -1,7 +1,6 @@ # Mistake #2: Unnecessary nested code #### TL;DR -TL;DR Avoiding nested levels and keeping the happy path aligned on the left makes building a mental code model easier. diff --git a/prompts/skills/100-go-mistakes/references/mistake-03-misusing-init-functions.md b/prompts/skills/100-go-mistakes/references/mistake-03-misusing-init-functions.md index 805677e..8695301 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-03-misusing-init-functions.md +++ b/prompts/skills/100-go-mistakes/references/mistake-03-misusing-init-functions.md @@ -1,7 +1,6 @@ # Mistake #3: Misusing init functions #### TL;DR -TL;DR When initializing variables, remember that init functions have limited error handling and make state handling and testing more complex. In most cases, initializations should be handled as specific functions. diff --git a/prompts/skills/100-go-mistakes/references/mistake-04-overusing-getters-and-setters.md b/prompts/skills/100-go-mistakes/references/mistake-04-overusing-getters-and-setters.md index a93dffc..d7730ef 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-04-overusing-getters-and-setters.md +++ b/prompts/skills/100-go-mistakes/references/mistake-04-overusing-getters-and-setters.md @@ -1,7 +1,6 @@ # Mistake #4: Overusing getters and setters #### TL;DR -TL;DR Forcing the use of getters and setters isn’t idiomatic in Go. Being pragmatic and finding the right balance between efficiency and blindly following certain idioms should be the way to go. diff --git a/prompts/skills/100-go-mistakes/references/mistake-05-interface-pollution.md b/prompts/skills/100-go-mistakes/references/mistake-05-interface-pollution.md index 00c9738..203be64 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-05-interface-pollution.md +++ b/prompts/skills/100-go-mistakes/references/mistake-05-interface-pollution.md @@ -1,7 +1,6 @@ # Mistake #5: Interface pollution #### TL;DR -TL;DR Abstractions should be discovered, not created. To prevent unnecessary complexity, create an interface when you need it and not when you foresee needing it, or if you can at least prove the abstraction to be a valid one. diff --git a/prompts/skills/100-go-mistakes/references/mistake-06-interface-on-the-producer-side.md b/prompts/skills/100-go-mistakes/references/mistake-06-interface-on-the-producer-side.md index d77acb7..ca7e752 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-06-interface-on-the-producer-side.md +++ b/prompts/skills/100-go-mistakes/references/mistake-06-interface-on-the-producer-side.md @@ -1,7 +1,6 @@ # Mistake #6: Interface on the producer side #### TL;DR -TL;DR Keeping interfaces on the client side avoids unnecessary abstractions. diff --git a/prompts/skills/100-go-mistakes/references/mistake-07-returning-interfaces.md b/prompts/skills/100-go-mistakes/references/mistake-07-returning-interfaces.md index f7c4fca..db52c2e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-07-returning-interfaces.md +++ b/prompts/skills/100-go-mistakes/references/mistake-07-returning-interfaces.md @@ -1,7 +1,6 @@ # Mistake #7: Returning interfaces #### TL;DR -TL;DR To prevent being restricted in terms of flexibility, a function shouldn’t return interfaces but concrete implementations in most cases. Conversely, a function should accept interfaces whenever possible. diff --git a/prompts/skills/100-go-mistakes/references/mistake-08-any-says-nothing.md b/prompts/skills/100-go-mistakes/references/mistake-08-any-says-nothing.md index af8a478..f7c8931 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-08-any-says-nothing.md +++ b/prompts/skills/100-go-mistakes/references/mistake-08-any-says-nothing.md @@ -1,3 +1,7 @@ # Mistake #8: any says nothing -[Documentation for mistake #8 from 100go.co] +#### TL;DR + +The `any` type can be helpful if there is a genuine need for accepting or returning any possible type (for instance, when it comes to marshaling or formatting). In general, we should avoid overgeneralizing the code we write at all costs. Perhaps a little bit of duplicated code might occasionally be better if it improves other aspects such as code expressiveness. + +[Source code](https://github.com/teivah/100-go-mistakes/tree/master/src/02-code-project-organization/8-any/main.go) diff --git a/prompts/skills/100-go-mistakes/references/mistake-09-being-confused-about-when-to-use-generics.md b/prompts/skills/100-go-mistakes/references/mistake-09-being-confused-about-when-to-use-generics.md index 64e10ce..120881f 100644 --- a/ |