diff options
96 files changed, 0 insertions, 98 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 54d5f69..09b9770 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,6 +1,5 @@ # Mistake #1: Unintended variable shadowing -#### 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 e8cf6c4..9b927fd 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,6 +1,5 @@ # Mistake #2: Unnecessary nested code -#### 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 8695301..3b7443d 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,6 +1,5 @@ # Mistake #3: Misusing init functions -#### 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 d7730ef..a36536f 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,6 +1,5 @@ # Mistake #4: Overusing getters and setters -#### 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 203be64..96f6958 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,6 +1,5 @@ # Mistake #5: Interface pollution -#### 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 ca7e752..01c0dea 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,6 +1,5 @@ # Mistake #6: Interface on the producer side -#### 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 db52c2e..d086108 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,6 +1,5 @@ # Mistake #7: Returning interfaces -#### 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 f7c8931..6d835e1 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,6 +1,5 @@ # Mistake #8: any says nothing -#### 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. 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 120881f..61792a4 100644 --- a/ |