diff options
| author | Paul Buetow <paul@buetow.org> | 2026-03-04 21:04:25 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2026-03-04 21:04:25 +0200 |
| commit | c4af21133a8a19635f1a8017e7d34f779f66f18e (patch) | |
| tree | 426b97f9f9343ef42964cab84dc4b6ff5fb0b106 | |
| parent | dba288dcfdccd41ec02cb02544d452769dd0a857 (diff) | |
chore: remove all TL;DR headers from reference files
Amp-Thread-ID: https://ampcode.com/threads/T-019cba2c-0536-70d9-956b-8ff115f07646
Co-authored-by: Amp <amp@ampcode.com>
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/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 @@ -1,6 +1,5 @@ # Mistake #9: Being confused about when to use generics -#### TL;DR Relying on generics and type parameters can prevent writing boilerplate code to factor out elements or behaviors. However, do not use type parameters prematurely, but only when you see a concrete need for them. Otherwise, they introduce unnecessary abstractions and complexity. diff --git a/prompts/skills/100-go-mistakes/references/mistake-10-not-being-aware-of-the-possible-problems-with-type-embedding.md b/prompts/skills/100-go-mistakes/references/mistake-10-not-being-aware-of-the-possible-problems-with-type-embedding.md index 0d6912c..5a19bb9 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-10-not-being-aware-of-the-possible-problems-with-type-embedding.md +++ b/prompts/skills/100-go-mistakes/references/mistake-10-not-being-aware-of-the-possible-problems-with-type-embedding.md @@ -1,6 +1,5 @@ # Mistake #10: Not being aware of the possible problems with type embedding -#### TL;DR Using type embedding can also help avoid boilerplate code; however, ensure that doing so doesn’t lead to visibility issues where some fields should have remained hidden. diff --git a/prompts/skills/100-go-mistakes/references/mistake-100-not-understanding-the-impacts-of-running-go-in-docker-and-kubernetes.md b/prompts/skills/100-go-mistakes/references/mistake-100-not-understanding-the-impacts-of-running-go-in-docker-and-kubernetes.md index 67c197c..de49740 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-100-not-understanding-the-impacts-of-running-go-in-docker-and-kubernetes.md +++ b/prompts/skills/100-go-mistakes/references/mistake-100-not-understanding-the-impacts-of-running-go-in-docker-and-kubernetes.md @@ -1,6 +1,5 @@ # Mistake #100: Not understanding the impacts of running Go in Docker and Kubernetes -#### TL;DR Be aware that `GOMAXPROCS` defaults to the number of OS-visible CPUs, not the container's CPU limit. Use libraries like `automaxprocs` to set it correctly based on cgroup limits. diff --git a/prompts/skills/100-go-mistakes/references/mistake-11-not-using-the-functional-options-pattern.md b/prompts/skills/100-go-mistakes/references/mistake-11-not-using-the-functional-options-pattern.md index 8179281..1cdf5a7 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-11-not-using-the-functional-options-pattern.md +++ b/prompts/skills/100-go-mistakes/references/mistake-11-not-using-the-functional-options-pattern.md @@ -1,6 +1,5 @@ # Mistake #11: Not using the functional options pattern -#### TL;DR To handle options conveniently and in an API-friendly manner, use the functional options pattern. diff --git a/prompts/skills/100-go-mistakes/references/mistake-12-project-misorganization-project-structure-and-package-organization.md b/prompts/skills/100-go-mistakes/references/mistake-12-project-misorganization-project-structure-and-package-organization.md index 53de0bd..3478f40 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-12-project-misorganization-project-structure-and-package-organization.md +++ b/prompts/skills/100-go-mistakes/references/mistake-12-project-misorganization-project-structure-and-package-organization.md @@ -11,7 +11,6 @@ Regarding what to export, the rule is pretty straightforward. We should minimize Organizing a project isn’t straightforward, but following these rules should help make it easier to maintain. However, remember that consistency is also vital to ease maintainability. Therefore, let’s make sure that we keep things as consistent as possible within a codebase. -#### TL;DR Note In 2023, the Go team has published an official guideline for organizing / structuring a Go project: go.dev/doc/modules/layout diff --git a/prompts/skills/100-go-mistakes/references/mistake-13-creating-utility-packages.md b/prompts/skills/100-go-mistakes/references/mistake-13-creating-utility-packages.md index 0e6c4f6..702d067 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-13-creating-utility-packages.md +++ b/prompts/skills/100-go-mistakes/references/mistake-13-creating-utility-packages.md @@ -1,6 +1,5 @@ # Mistake #13: Creating utility packages -#### TL;DR Naming is a critical piece of application design. Creating packages such as `common`, `util`, and `shared` doesn’t bring much value for the reader. Refactor such packages into meaningful and specific package names. diff --git a/prompts/skills/100-go-mistakes/references/mistake-14-ignoring-package-name-collisions.md b/prompts/skills/100-go-mistakes/references/mistake-14-ignoring-package-name-collisions.md index eee965c..3330da1 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-14-ignoring-package-name-collisions.md +++ b/prompts/skills/100-go-mistakes/references/mistake-14-ignoring-package-name-collisions.md @@ -1,6 +1,5 @@ # Mistake #14: Ignoring package name collisions -#### TL;DR To avoid naming collisions between variables and packages, leading to confusion or perhaps even bugs, use unique names for each one. If this isn’t feasible, use an import alias to change the qualifier to differentiate the package name from the variable name, or think of a better name. diff --git a/prompts/skills/100-go-mistakes/references/mistake-15-missing-code-documentation.md b/prompts/skills/100-go-mistakes/references/mistake-15-missing-code-documentation.md index f9fdc8e..231a31b 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-15-missing-code-documentation.md +++ b/prompts/skills/100-go-mistakes/references/mistake-15-missing-code-documentation.md @@ -1,6 +1,5 @@ # Mistake #15: Missing code documentation -#### TL;DR To help clients and maintainers understand your code’s purpose, document exported elements. diff --git a/prompts/skills/100-go-mistakes/references/mistake-16-not-using-linters.md b/prompts/skills/100-go-mistakes/references/mistake-16-not-using-linters.md index 1106f75..d62d362 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-16-not-using-linters.md +++ b/prompts/skills/100-go-mistakes/references/mistake-16-not-using-linters.md @@ -1,6 +1,5 @@ # Mistake #16: Not using linters -#### TL;DR To improve code quality and consistency, use linters and formatters. diff --git a/prompts/skills/100-go-mistakes/references/mistake-17-creating-confusion-with-octal-literals.md b/prompts/skills/100-go-mistakes/references/mistake-17-creating-confusion-with-octal-literals.md index 010f574..d654203 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-17-creating-confusion-with-octal-literals.md +++ b/prompts/skills/100-go-mistakes/references/mistake-17-creating-confusion-with-octal-literals.md @@ -1,6 +1,5 @@ # Mistake #17: Creating confusion with octal literals -#### TL;DR When reading existing code, bear in mind that integer literals starting with `0` are octal numbers. Also, to improve readability, make octal integers explicit by prefixing them with `0o`. diff --git a/prompts/skills/100-go-mistakes/references/mistake-18-neglecting-integer-overflows.md b/prompts/skills/100-go-mistakes/references/mistake-18-neglecting-integer-overflows.md index f0e35ee..39293aa 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-18-neglecting-integer-overflows.md +++ b/prompts/skills/100-go-mistakes/references/mistake-18-neglecting-integer-overflows.md @@ -1,6 +1,5 @@ # Mistake #18: Neglecting integer overflows -#### TL;DR Because integer overflows and underflows are handled silently in Go, you can implement your own functions to catch them. diff --git a/prompts/skills/100-go-mistakes/references/mistake-19-not-understanding-floating-points.md b/prompts/skills/100-go-mistakes/references/mistake-19-not-understanding-floating-points.md index 85867e6..342830e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-19-not-understanding-floating-points.md +++ b/prompts/skills/100-go-mistakes/references/mistake-19-not-understanding-floating-points.md @@ -1,6 +1,5 @@ # Mistake #19: Not understanding floating-points -#### TL;DR Making floating-point comparisons within a given delta can ensure that your code is portable. When performing addition or subtraction, group the operations with a similar order of magnitude to favor accuracy. Also, perform multiplication and division before addition and subtraction. diff --git a/prompts/skills/100-go-mistakes/references/mistake-20-not-understanding-slice-length-and-capacity.md b/prompts/skills/100-go-mistakes/references/mistake-20-not-understanding-slice-length-and-capacity.md index 7fb89cb..d93cce1 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-20-not-understanding-slice-length-and-capacity.md +++ b/prompts/skills/100-go-mistakes/references/mistake-20-not-understanding-slice-length-and-capacity.md @@ -1,6 +1,5 @@ # Mistake #20: Not understanding slice length and capacity -#### TL;DR Understanding the difference between slice length and capacity should be part of a Go developer’s core knowledge. The slice length is the number of available elements in the slice, whereas the slice capacity is the number of elements in the backing array. diff --git a/prompts/skills/100-go-mistakes/references/mistake-21-inefficient-slice-initialization.md b/prompts/skills/100-go-mistakes/references/mistake-21-inefficient-slice-initialization.md index 024a2c1..f2c63ff 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-21-inefficient-slice-initialization.md +++ b/prompts/skills/100-go-mistakes/references/mistake-21-inefficient-slice-initialization.md @@ -1,6 +1,5 @@ # Mistake #21: Inefficient slice initialization -#### TL;DR When creating a slice, initialize it with a given length or capacity if its length is already known. This reduces the number of allocations and improves performance. diff --git a/prompts/skills/100-go-mistakes/references/mistake-22-being-confused-about-nil-vs-empty-slice.md b/prompts/skills/100-go-mistakes/references/mistake-22-being-confused-about-nil-vs-empty-slice.md index 528508e..dc5b5dc 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-22-being-confused-about-nil-vs-empty-slice.md +++ b/prompts/skills/100-go-mistakes/references/mistake-22-being-confused-about-nil-vs-empty-slice.md @@ -1,6 +1,5 @@ # Mistake #22: Being confused about nil vs. empty slice -#### TL;DR To prevent common confusions such as when using the `encoding/json` or the `reflect` package, you need to understand the difference between nil and empty slices. Both are zero-length, zero-capacity slices, but only a nil slice doesn’t require allocation. diff --git a/prompts/skills/100-go-mistakes/references/mistake-23-not-properly-checking-if-a-slice-is-empty.md b/prompts/skills/100-go-mistakes/references/mistake-23-not-properly-checking-if-a-slice-is-empty.md index 9b734e8..19fa26f 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-23-not-properly-checking-if-a-slice-is-empty.md +++ b/prompts/skills/100-go-mistakes/references/mistake-23-not-properly-checking-if-a-slice-is-empty.md @@ -1,6 +1,5 @@ # Mistake #23: Not properly checking if a slice is empty -#### TL;DR To check if a slice doesn’t contain any element, check its length. This check works regardless of whether the slice is `nil` or empty. The same goes for maps. To design unambiguous APIs, you shouldn’t distinguish between nil and empty slices. diff --git a/prompts/skills/100-go-mistakes/references/mistake-24-not-making-slice-copies-correctly.md b/prompts/skills/100-go-mistakes/references/mistake-24-not-making-slice-copies-correctly.md index 0fa368a..1a369fe 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-24-not-making-slice-copies-correctly.md +++ b/prompts/skills/100-go-mistakes/references/mistake-24-not-making-slice-copies-correctly.md @@ -1,6 +1,5 @@ # Mistake #24: Not making slice copies correctly -#### TL;DR To copy one slice to another using the `copy` built-in function, remember that the number of copied elements corresponds to the minimum between the two slice’s lengths. diff --git a/prompts/skills/100-go-mistakes/references/mistake-25-unexpected-side-effects-using-slice-append.md b/prompts/skills/100-go-mistakes/references/mistake-25-unexpected-side-effects-using-slice-append.md index b38083f..87637c9 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-25-unexpected-side-effects-using-slice-append.md +++ b/prompts/skills/100-go-mistakes/references/mistake-25-unexpected-side-effects-using-slice-append.md @@ -1,6 +1,5 @@ # Mistake #25: Unexpected side effects using slice append -#### TL;DR Using copy or the full slice expression is a way to prevent `append` from creating conflicts if two different functions use slices backed by the same array. However, only a slice copy prevents memory leaks if you want to shrink a large slice. diff --git a/prompts/skills/100-go-mistakes/references/mistake-26-slices-and-memory-leaks.md b/prompts/skills/100-go-mistakes/references/mistake-26-slices-and-memory-leaks.md index 78474a3..5c97ff0 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-26-slices-and-memory-leaks.md +++ b/prompts/skills/100-go-mistakes/references/mistake-26-slices-and-memory-leaks.md @@ -1,6 +1,5 @@ # Mistake #26: Slices and memory leaks -#### TL;DR Working with a slice of pointers or structs with pointer fields, you can avoid memory leaks by marking as nil the elements excluded by a slicing operation. diff --git a/prompts/skills/100-go-mistakes/references/mistake-27-inefficient-map-initialization.md b/prompts/skills/100-go-mistakes/references/mistake-27-inefficient-map-initialization.md index 3328921..7d755ec 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-27-inefficient-map-initialization.md +++ b/prompts/skills/100-go-mistakes/references/mistake-27-inefficient-map-initialization.md @@ -1,6 +1,5 @@ # Mistake #27: Inefficient map initialization -#### TL;DR When creating a map, initialize it with a given length if its length is already known. This reduces the number of allocations and improves performance. diff --git a/prompts/skills/100-go-mistakes/references/mistake-28-maps-and-memory-leaks.md b/prompts/skills/100-go-mistakes/references/mistake-28-maps-and-memory-leaks.md index 7fb8f7e..6286b0f 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-28-maps-and-memory-leaks.md +++ b/prompts/skills/100-go-mistakes/references/mistake-28-maps-and-memory-leaks.md @@ -1,6 +1,5 @@ # Mistake #28: Maps and memory leaks -#### TL;DR A map can always grow in memory, but it never shrinks. Hence, if it leads to some memory issues, you can try different options, such as forcing Go to recreate the map or using pointers. diff --git a/prompts/skills/100-go-mistakes/references/mistake-29-comparing-values-incorrectly.md b/prompts/skills/100-go-mistakes/references/mistake-29-comparing-values-incorrectly.md index daef02a..d0960bc 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-29-comparing-values-incorrectly.md +++ b/prompts/skills/100-go-mistakes/references/mistake-29-comparing-values-incorrectly.md @@ -1,6 +1,5 @@ # Mistake #29: Comparing values incorrectly -#### TL;DR To compare types in Go, you can use the == and != operators if two types are comparable: Booleans, numerals, strings, pointers, channels, and structs are composed entirely of comparable types. Otherwise, you can either use `reflect.DeepEqual` and pay the price of reflection or use custom implementations and libraries. diff --git a/prompts/skills/100-go-mistakes/references/mistake-30-ignoring-that-elements-are-copied-in-range-loops.md b/prompts/skills/100-go-mistakes/references/mistake-30-ignoring-that-elements-are-copied-in-range-loops.md index 83a9c1a..6b81e61 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-30-ignoring-that-elements-are-copied-in-range-loops.md +++ b/prompts/skills/100-go-mistakes/references/mistake-30-ignoring-that-elements-are-copied-in-range-loops.md @@ -1,6 +1,5 @@ # Mistake #30: Ignoring that elements are copied in range loops -#### TL;DR The value element in a range loop is a copy. Therefore, to mutate a struct, use the index to access it directly or use a classic for loop with pointers. diff --git a/prompts/skills/100-go-mistakes/references/mistake-31-ignoring-how-arguments-are-evaluated-in-range-loops-channels-and-arrays.md b/prompts/skills/100-go-mistakes/references/mistake-31-ignoring-how-arguments-are-evaluated-in-range-loops-channels-and-arrays.md index 7a16c53..3143ffd 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-31-ignoring-how-arguments-are-evaluated-in-range-loops-channels-and-arrays.md +++ b/prompts/skills/100-go-mistakes/references/mistake-31-ignoring-how-arguments-are-evaluated-in-range-loops-channels-and-arrays.md @@ -1,6 +1,5 @@ # Mistake #31: Ignoring how arguments are evaluated in range loops (channels and arrays) -#### TL;DR The range loop expression is evaluated only once, before the beginning of the loop, by doing a copy. Be aware of this to avoid common mistakes. diff --git a/prompts/skills/100-go-mistakes/references/mistake-32-ignoring-the-impacts-of-using-pointer-elements-in-range-loops.md b/prompts/skills/100-go-mistakes/references/mistake-32-ignoring-the-impacts-of-using-pointer-elements-in-range-loops.md index c6e02c3..1e87705 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-32-ignoring-the-impacts-of-using-pointer-elements-in-range-loops.md +++ b/prompts/skills/100-go-mistakes/references/mistake-32-ignoring-the-impacts-of-using-pointer-elements-in-range-loops.md @@ -1,6 +1,5 @@ # Mistake #32: Ignoring the impacts of using pointer elements in range loops -#### TL;DR When iterating over a data structure using a range loop and storing the pointer of each element, be aware that all pointers will point to the same element: the last one. Use a local variable or index access instead. diff --git a/prompts/skills/100-go-mistakes/references/mistake-33-making-wrong-assumptions-during-map-iterations-ordering-and-map-insert-during-iteration.md b/prompts/skills/100-go-mistakes/references/mistake-33-making-wrong-assumptions-during-map-iterations-ordering-and-map-insert-during-iteration.md index 10c3f19..e20e801 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-33-making-wrong-assumptions-during-map-iterations-ordering-and-map-insert-during-iteration.md +++ b/prompts/skills/100-go-mistakes/references/mistake-33-making-wrong-assumptions-during-map-iterations-ordering-and-map-insert-during-iteration.md @@ -1,6 +1,5 @@ # Mistake #33: Making wrong assumptions during map iterations (ordering and map insert during iteration) -#### TL;DR To ensure predictable outputs when using maps, remember that a map data structure: diff --git a/prompts/skills/100-go-mistakes/references/mistake-34-ignoring-how-the-break-statement-works.md b/prompts/skills/100-go-mistakes/references/mistake-34-ignoring-how-the-break-statement-works.md index 594de48..6bb4845 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-34-ignoring-how-the-break-statement-works.md +++ b/prompts/skills/100-go-mistakes/references/mistake-34-ignoring-how-the-break-statement-works.md @@ -1,6 +1,5 @@ # Mistake #34: Ignoring how the break statement works -#### TL;DR A `break` statement terminates the execution of the innermost `for`, `switch`, or `select` statement. Use labels to break out of an outer loop from within a `switch` or `select`. diff --git a/prompts/skills/100-go-mistakes/references/mistake-35-using-defer-inside-a-loop.md b/prompts/skills/100-go-mistakes/references/mistake-35-using-defer-inside-a-loop.md index f0dff21..3a222e7 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-35-using-defer-inside-a-loop.md +++ b/prompts/skills/100-go-mistakes/references/mistake-35-using-defer-inside-a-loop.md @@ -1,6 +1,5 @@ # Mistake #35: Using defer inside a loop -#### TL;DR A `defer` call is executed not during each loop iteration but when the surrounding function returns. Be cautious about using `defer` inside loops; extract the loop body into a function to ensure `defer` executes per iteration. diff --git a/prompts/skills/100-go-mistakes/references/mistake-36-not-understanding-the-concept-of-rune.md b/prompts/skills/100-go-mistakes/references/mistake-36-not-understanding-the-concept-of-rune.md index c4c97e7..9b86c24 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-36-not-understanding-the-concept-of-rune.md +++ b/prompts/skills/100-go-mistakes/references/mistake-36-not-understanding-the-concept-of-rune.md @@ -1,6 +1,5 @@ # Mistake #36: Not understanding the concept of rune -#### TL;DR Understanding that a rune corresponds to the concept of a Unicode code point and that it can be composed of multiple bytes should be part of the Go developer’s core knowledge to work accurately with strings. diff --git a/prompts/skills/100-go-mistakes/references/mistake-37-inaccurate-string-iteration.md b/prompts/skills/100-go-mistakes/references/mistake-37-inaccurate-string-iteration.md index b3e83bd..e421a6e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-37-inaccurate-string-iteration.md +++ b/prompts/skills/100-go-mistakes/references/mistake-37-inaccurate-string-iteration.md @@ -1,6 +1,5 @@ # Mistake #37: Inaccurate string iteration -#### TL;DR Iterating on a string with the `range` operator iterates on the runes with the index corresponding to the starting index of the rune’s byte sequence. To access a specific rune index (such as the third rune), convert the string into a `[]rune`. diff --git a/prompts/skills/100-go-mistakes/references/mistake-38-misusing-trim-functions.md b/prompts/skills/100-go-mistakes/references/mistake-38-misusing-trim-functions.md index 177c373..f5516a3 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-38-misusing-trim-functions.md +++ b/prompts/skills/100-go-mistakes/references/mistake-38-misusing-trim-functions.md @@ -1,6 +1,5 @@ # Mistake #38: Misusing trim functions -#### TL;DR `strings.TrimRight`/`strings.TrimLeft` removes all the trailing/leading runes contained in a given set, whereas `strings.TrimSuffix`/`strings.TrimPrefix` returns a string without a provided suffix/prefix. diff --git a/prompts/skills/100-go-mistakes/references/mistake-39-under-optimized-strings-concatenation.md b/prompts/skills/100-go-mistakes/references/mistake-39-under-optimized-strings-concatenation.md index 862225c..15cf246 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-39-under-optimized-strings-concatenation.md +++ b/prompts/skills/100-go-mistakes/references/mistake-39-under-optimized-strings-concatenation.md @@ -1,6 +1,5 @@ # Mistake #39: Under-optimized strings concatenation -#### TL;DR Concatenating a list of strings should be done with `strings.Builder` to prevent allocating a new string during each iteration. diff --git a/prompts/skills/100-go-mistakes/references/mistake-40-useless-string-conversions.md b/prompts/skills/100-go-mistakes/references/mistake-40-useless-string-conversions.md index 5301d23..8699b65 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-40-useless-string-conversions.md +++ b/prompts/skills/100-go-mistakes/references/mistake-40-useless-string-conversions.md @@ -1,6 +1,5 @@ # Mistake #40: Useless string conversions -#### TL;DR Remembering that the `bytes` package offers the same operations as the `strings` package can help avoid extra byte/string conversions. diff --git a/prompts/skills/100-go-mistakes/references/mistake-41-substring-and-memory-leaks.md b/prompts/skills/100-go-mistakes/references/mistake-41-substring-and-memory-leaks.md index 5b5d0e6..c91c6a8 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-41-substring-and-memory-leaks.md +++ b/prompts/skills/100-go-mistakes/references/mistake-41-substring-and-memory-leaks.md @@ -1,6 +1,5 @@ # Mistake #41: Substring and memory leaks -#### TL;DR Using copies instead of substrings can prevent memory leaks, as the string returned by a substring operation will be backed by the same byte array. diff --git a/prompts/skills/100-go-mistakes/references/mistake-42-not-knowing-which-type-of-receiver-to-use.md b/prompts/skills/100-go-mistakes/references/mistake-42-not-knowing-which-type-of-receiver-to-use.md index 1d7bd35..7d09dc9 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-42-not-knowing-which-type-of-receiver-to-use.md +++ b/prompts/skills/100-go-mistakes/references/mistake-42-not-knowing-which-type-of-receiver-to-use.md @@ -1,6 +1,5 @@ # Mistake #42: Not knowing which type of receiver to use -#### TL;DR The decision whether to use a value or a pointer receiver should be made based on factors such as the type, whether it has to be mutated, whether it contains a field that can’t be copied, and how large the object is. When in doubt, use a pointer receiver. diff --git a/prompts/skills/100-go-mistakes/references/mistake-43-never-using-named-result-parameters.md b/prompts/skills/100-go-mistakes/references/mistake-43-never-using-named-result-parameters.md index 3bc2ac4..7348bec 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-43-never-using-named-result-parameters.md +++ b/prompts/skills/100-go-mistakes/references/mistake-43-never-using-named-result-parameters.md @@ -1,6 +1,5 @@ # Mistake #43: Never using named result parameters -#### TL;DR Using named result parameters can be an efficient way to improve the readability of a function/method, especially if multiple result parameters have the same type. In some cases, this approach can also be convenient because named result parameters are initialized to their zero value. But be cautious about potential side effects. diff --git a/prompts/skills/100-go-mistakes/references/mistake-44-unintended-side-effects-with-named-result-parameters.md b/prompts/skills/100-go-mistakes/references/mistake-44-unintended-side-effects-with-named-result-parameters.md index 2230494..a4e4763 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-44-unintended-side-effects-with-named-result-parameters.md +++ b/prompts/skills/100-go-mistakes/references/mistake-44-unintended-side-effects-with-named-result-parameters.md @@ -1,6 +1,5 @@ # Mistake #44: Unintended side effects with named result parameters -#### TL;DR See #43. diff --git a/prompts/skills/100-go-mistakes/references/mistake-45-returning-a-nil-receiver.md b/prompts/skills/100-go-mistakes/references/mistake-45-returning-a-nil-receiver.md index a2f869b..d3f4b0a 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-45-returning-a-nil-receiver.md +++ b/prompts/skills/100-go-mistakes/references/mistake-45-returning-a-nil-receiver.md @@ -1,6 +1,5 @@ # Mistake #45: Returning a nil receiver -#### TL;DR When returning an interface, be cautious about not returning a nil pointer but an explicit nil value. Otherwise, unintended consequences may occur and the caller will receive a non-nil value. diff --git a/prompts/skills/100-go-mistakes/references/mistake-46-using-a-filename-as-a-function-input.md b/prompts/skills/100-go-mistakes/references/mistake-46-using-a-filename-as-a-function-input.md index 860f9ef..73a360a 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-46-using-a-filename-as-a-function-input.md +++ b/prompts/skills/100-go-mistakes/references/mistake-46-using-a-filename-as-a-function-input.md @@ -1,6 +1,5 @@ # Mistake #46: Using a filename as a function input -#### TL;DR Designing functions to receive `io.Reader` types instead of filenames improves the reusability of a function and makes testing easier. diff --git a/prompts/skills/100-go-mistakes/references/mistake-47-ignoring-how-defer-arguments-and-receivers-are-evaluated.md b/prompts/skills/100-go-mistakes/references/mistake-47-ignoring-how-defer-arguments-and-receivers-are-evaluated.md index 3e6818f..a1f0177 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-47-ignoring-how-defer-arguments-and-receivers-are-evaluated.md +++ b/prompts/skills/100-go-mistakes/references/mistake-47-ignoring-how-defer-arguments-and-receivers-are-evaluated.md @@ -1,6 +1,5 @@ # Mistake #47: Ignoring how defer arguments and receivers are evaluated -#### TL;DR In a `defer` function, arguments are evaluated right away, not once the surrounding function returns. To defer a call with an updated value, use pointers or closures. diff --git a/prompts/skills/100-go-mistakes/references/mistake-48-panicking.md b/prompts/skills/100-go-mistakes/references/mistake-48-panicking.md index e2ac88e..e58a06c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-48-panicking.md +++ b/prompts/skills/100-go-mistakes/references/mistake-48-panicking.md @@ -1,6 +1,5 @@ # Mistake #48: Panicking -#### TL;DR Using `panic` is an option to deal with errors in Go. However, it should only be used sparingly in unrecoverable conditions: for example, to signal a programmer error or when you fail to load a mandatory dependency. diff --git a/prompts/skills/100-go-mistakes/references/mistake-49-ignoring-when-to-wrap-an-error.md b/prompts/skills/100-go-mistakes/references/mistake-49-ignoring-when-to-wrap-an-error.md index dffec32..55e747f 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-49-ignoring-when-to-wrap-an-error.md +++ b/prompts/skills/100-go-mistakes/references/mistake-49-ignoring-when-to-wrap-an-error.md @@ -1,6 +1,5 @@ # Mistake #49: Ignoring when to wrap an error -#### TL;DR Wrapping an error allows you to mark an error and/or provide additional context. However, error wrapping creates potential coupling as it makes the source error available for the caller. If you want to prevent that, don’t use error wrapping. diff --git a/prompts/skills/100-go-mistakes/references/mistake-50-comparing-an-error-type-inaccurately.md b/prompts/skills/100-go-mistakes/references/mistake-50-comparing-an-error-type-inaccurately.md index 4a0f122..dfea107 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-50-comparing-an-error-type-inaccurately.md +++ b/prompts/skills/100-go-mistakes/references/mistake-50-comparing-an-error-type-inaccurately.md @@ -1,6 +1,5 @@ # Mistake #50: Comparing an error type inaccurately -#### TL;DR If you use Go 1.13 error wrapping with the `%w` directive and `fmt.Errorf`, comparing an error against a type has to be done using `errors.As`. Otherwise, if the returned error you want to check is wrapped, it will fail the checks. diff --git a/prompts/skills/100-go-mistakes/references/mistake-51-comparing-an-error-value-inaccurately.md b/prompts/skills/100-go-mistakes/references/mistake-51-comparing-an-error-value-inaccurately.md index 6ad5963..e276d70 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-51-comparing-an-error-value-inaccurately.md +++ b/prompts/skills/100-go-mistakes/references/mistake-51-comparing-an-error-value-inaccurately.md @@ -1,6 +1,5 @@ # Mistake #51: Comparing an error value inaccurately -#### TL;DR If you use Go 1.13 error wrapping with the `%w` directive and `fmt.Errorf`, comparing an error against or a value has to be done using `errors.As`. Otherwise, if the returned error you want to check is wrapped, it will fail the checks. diff --git a/prompts/skills/100-go-mistakes/references/mistake-52-handling-an-error-twice.md b/prompts/skills/100-go-mistakes/references/mistake-52-handling-an-error-twice.md index 2e2869a..278417c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-52-handling-an-error-twice.md +++ b/prompts/skills/100-go-mistakes/references/mistake-52-handling-an-error-twice.md @@ -1,6 +1,5 @@ # Mistake #52: Handling an error twice -#### TL;DR In most situations, an error should be handled only once. Logging an error is handling an error. Therefore, you have to choose between logging or returning an error. In many cases, error wrapping is the solution as it allows you to provide additional context to an error and return the source error. diff --git a/prompts/skills/100-go-mistakes/references/mistake-53-not-handling-an-error.md b/prompts/skills/100-go-mistakes/references/mistake-53-not-handling-an-error.md index f7bc7c7..1d61c29 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-53-not-handling-an-error.md +++ b/prompts/skills/100-go-mistakes/references/mistake-53-not-handling-an-error.md @@ -1,6 +1,5 @@ # Mistake #53: Not handling an error -#### TL;DR Ignoring an error, whether during a function call or in a `defer` function, should be done explicitly using the blank identifier. Otherwise, future readers may be confused about whether it was intentional or a miss. diff --git a/prompts/skills/100-go-mistakes/references/mistake-54-not-handling-defer-errors.md b/prompts/skills/100-go-mistakes/references/mistake-54-not-handling-defer-errors.md index 111ead8..73b798b 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-54-not-handling-defer-errors.md +++ b/prompts/skills/100-go-mistakes/references/mistake-54-not-handling-defer-errors.md @@ -1,6 +1,5 @@ # Mistake #54: Not handling defer errors -#### TL;DR When we want to ignore an error in a `defer` call, use the blank identifier (`_`) to make it explicit and add a comment explaining why. diff --git a/prompts/skills/100-go-mistakes/references/mistake-55-mixing-up-concurrency-and-parallelism.md b/prompts/skills/100-go-mistakes/references/mistake-55-mixing-up-concurrency-and-parallelism.md index f619e0b..8e42fb2 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-55-mixing-up-concurrency-and-parallelism.md +++ b/prompts/skills/100-go-mistakes/references/mistake-55-mixing-up-concurrency-and-parallelism.md @@ -1,6 +1,5 @@ # Mistake #55: Mixing up concurrency and parallelism -#### TL;DR Understanding the fundamental differences between concurrency and parallelism is a cornerstone of the Go developer’s knowledge. Concurrency is about structure, whereas parallelism is about execution. diff --git a/prompts/skills/100-go-mistakes/references/mistake-56-thinking-concurrency-is-always-faster.md b/prompts/skills/100-go-mistakes/references/mistake-56-thinking-concurrency-is-always-faster.md index 53e09f6..c226301 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-56-thinking-concurrency-is-always-faster.md +++ b/prompts/skills/100-go-mistakes/references/mistake-56-thinking-concurrency-is-always-faster.md @@ -1,6 +1,5 @@ # Mistake #56: Thinking concurrency is always faster -#### TL;DR To be a proficient developer, you must acknowledge that concurrency isn’t always faster. Solutions involving parallelization of minimal workloads may not necessarily be faster than a sequential implementation. Benchmarking sequential versus concurrent solutions should be the way to validate assumptions. diff --git a/prompts/skills/100-go-mistakes/references/mistake-57-being-puzzled-about-when-to-use-channels-or-mutexes.md b/prompts/skills/100-go-mistakes/references/mistake-57-being-puzzled-about-when-to-use-channels-or-mutexes.md index 29310ad..5eb74ac 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-57-being-puzzled-about-when-to-use-channels-or-mutexes.md +++ b/prompts/skills/100-go-mistakes/references/mistake-57-being-puzzled-about-when-to-use-channels-or-mutexes.md @@ -1,6 +1,5 @@ # Mistake #57: Being puzzled about when to use channels or mutexes -#### TL;DR Being aware of goroutine interactions can also be helpful when deciding between channels and mutexes. In general, parallel goroutines require synchronization and hence mutexes. Conversely, concurrent goroutines generally require coordination and orchestration and hence channels. diff --git a/prompts/skills/100-go-mistakes/references/mistake-58-not-understanding-race-problems-data-races-vs-race-conditions.md b/prompts/skills/100-go-mistakes/references/mistake-58-not-understanding-race-problems-data-races-vs-race-conditions.md index 418b909..97d374c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-58-not-understanding-race-problems-data-races-vs-race-conditions.md +++ b/prompts/skills/100-go-mistakes/references/mistake-58-not-understanding-race-problems-data-races-vs-race-conditions.md @@ -1,6 +1,5 @@ # Mistake #58: Not understanding race problems (data races vs. race conditions and the Go memory model) -#### TL;DR Being proficient in concurrency also means understanding that data races and race conditions are different concepts. Data races occur when multiple goroutines simultaneously access the same memory location and at least one of them is writing. Meanwhile, being data-race-free doesn’t necessarily mean deterministic execution. When a behavior depends on the sequence or the timing of events that can’t be controlled, this is a race condition. diff --git a/prompts/skills/100-go-mistakes/references/mistake-59-not-understanding-the-concurrency-impacts-of-a-workload-type.md b/prompts/skills/100-go-mistakes/references/mistake-59-not-understanding-the-concurrency-impacts-of-a-workload-type.md index 0a60da5..141fb69 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-59-not-understanding-the-concurrency-impacts-of-a-workload-type.md +++ b/prompts/skills/100-go-mistakes/references/mistake-59-not-understanding-the-concurrency-impacts-of-a-workload-type.md @@ -1,6 +1,5 @@ # Mistake #59: Not understanding the concurrency impacts of a workload type -#### TL;DR When creating a certain number of goroutines, consider the workload type. Creating CPU-bound goroutines means bounding this number close to the GOMAXPROCS variable (based by default on the number of CPU cores on the host). Creating I/O-bound goroutines depends on other factors, such as the external system. @@ -10,7 +9,6 @@ In programming, the execution time of a workload is limited by one of the follow * The speed of I/O—For example, making a REST call or a database query. The workload is called I/O-bound. * The amount of available memory—The workload is called memory-bound. -#### TL;DR Note The last is the rarest nowadays, given that memory has become very cheap in recent decades. Hence, this section focuses on the two first workload types: CPU- and I/O-bound. diff --git a/prompts/skills/100-go-mistakes/references/mistake-60-misunderstanding-go-contexts.md b/prompts/skills/100-go-mistakes/references/mistake-60-misunderstanding-go-contexts.md index fe44998..8ab50c3 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-60-misunderstanding-go-contexts.md +++ b/prompts/skills/100-go-mistakes/references/mistake-60-misunderstanding-go-contexts.md @@ -1,6 +1,5 @@ # Mistake #60: Misunderstanding Go contexts -#### TL;DR Go contexts are also one of the cornerstones of concurrency in Go. A context allows you to carry a deadline, a cancellation signal, and/or a list of keys-values. diff --git a/prompts/skills/100-go-mistakes/references/mistake-61-propagating-an-inappropriate-context.md b/prompts/skills/100-go-mistakes/references/mistake-61-propagating-an-inappropriate-context.md index 8fa7b09..e6555ef 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-61-propagating-an-inappropriate-context.md +++ b/prompts/skills/100-go-mistakes/references/mistake-61-propagating-an-inappropriate-context.md @@ -1,6 +1,5 @@ # Mistake #61: Propagating an inappropriate context -#### TL;DR Understanding the conditions when a context can be canceled should matter when propagating it: for example, an HTTP handler canceling the context when the response has been sent. @@ -36,7 +35,6 @@ When the response has been written to the client, the context associated with th In the latter case, calling publish will return an error because we returned the HTTP response quickly. -#### TL;DR Note From Go 1.21, there is a way to create a new context without cancel. `context.WithoutCancel` returns a copy of parent that is not canceled when parent is canceled. diff --git a/prompts/skills/100-go-mistakes/references/mistake-62-starting-a-goroutine-without-knowing-when-to-stop-it.md b/prompts/skills/100-go-mistakes/references/mistake-62-starting-a-goroutine-without-knowing-when-to-stop-it.md index 6438377..55251a7 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-62-starting-a-goroutine-without-knowing-when-to-stop-it.md +++ b/prompts/skills/100-go-mistakes/references/mistake-62-starting-a-goroutine-without-knowing-when-to-stop-it.md @@ -1,6 +1,5 @@ # Mistake #62: Starting a goroutine without knowing when to stop it -#### TL;DR Avoiding leaks means being mindful that whenever a goroutine is started, you should have a plan to stop it eventually. diff --git a/prompts/skills/100-go-mistakes/references/mistake-63-not-being-careful-with-goroutines-and-loop-variables.md b/prompts/skills/100-go-mistakes/references/mistake-63-not-being-careful-with-goroutines-and-loop-variables.md index ed7d1c3..7f80baa 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-63-not-being-careful-with-goroutines-and-loop-variables.md +++ b/prompts/skills/100-go-mistakes/references/mistake-63-not-being-careful-with-goroutines-and-loop-variables.md @@ -1,6 +1,5 @@ # Mistake #63: Not being careful with goroutines and loop variables -#### TL;DR When launching goroutines from within a loop, be aware that the loop variable is shared across all iterations (prior to Go 1.22). Pass it as a parameter or create a local copy to avoid all goroutines referencing the last value. diff --git a/prompts/skills/100-go-mistakes/references/mistake-64-expecting-a-deterministic-behavior-using-select-and-channels.md b/prompts/skills/100-go-mistakes/references/mistake-64-expecting-a-deterministic-behavior-using-select-and-channels.md index fdbba40..34b509c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-64-expecting-a-deterministic-behavior-using-select-and-channels.md +++ b/prompts/skills/100-go-mistakes/references/mistake-64-expecting-a-deterministic-behavior-using-select-and-channels.md @@ -1,6 +1,5 @@ # Mistake #64: Expecting a deterministic behavior using select and channels -#### TL;DR Understanding that `select` with multiple channels chooses the case randomly if multiple options are possible prevents making wrong assumptions that can lead to subtle concurrency bugs. diff --git a/prompts/skills/100-go-mistakes/references/mistake-65-not-using-notification-channels.md b/prompts/skills/100-go-mistakes/references/mistake-65-not-using-notification-channels.md index db66f67..511976c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-65-not-using-notification-channels.md +++ b/prompts/skills/100-go-mistakes/references/mistake-65-not-using-notification-channels.md @@ -1,6 +1,5 @@ # Mistake #65: Not using notification channels -#### TL;DR Send notifications using a `chan struct{}` type. diff --git a/prompts/skills/100-go-mistakes/references/mistake-66-not-using-nil-channels.md b/prompts/skills/100-go-mistakes/references/mistake-66-not-using-nil-channels.md index 91e298b..992c801 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-66-not-using-nil-channels.md +++ b/prompts/skills/100-go-mistakes/references/mistake-66-not-using-nil-channels.md @@ -1,6 +1,5 @@ # Mistake #66: Not using nil channels -#### TL;DR Using nil channels should be part of your concurrency toolset because it allows you to remove cases from `select` statements, for example. diff --git a/prompts/skills/100-go-mistakes/references/mistake-67-being-puzzled-about-channel-size.md b/prompts/skills/100-go-mistakes/references/mistake-67-being-puzzled-about-channel-size.md index 8b3d867..5df5446 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-67-being-puzzled-about-channel-size.md +++ b/prompts/skills/100-go-mistakes/references/mistake-67-being-puzzled-about-channel-size.md @@ -1,6 +1,5 @@ # Mistake #67: Being puzzled about channel size -#### TL;DR Carefully decide on the right channel type to use, given a problem. Only unbuffered channels provide strong synchronization guarantees. For buffered channels, you should have a good reason to specify a channel size other than one. diff --git a/prompts/skills/100-go-mistakes/references/mistake-68-forgetting-about-possible-side-effects-with-string-formatting.md b/prompts/skills/100-go-mistakes/references/mistake-68-forgetting-about-possible-side-effects-with-string-formatting.md index 3f09eef..d7b3fdc 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-68-forgetting-about-possible-side-effects-with-string-formatting.md +++ b/prompts/skills/100-go-mistakes/references/mistake-68-forgetting-about-possible-side-effects-with-string-formatting.md @@ -1,6 +1,5 @@ # Mistake #68: Forgetting about possible side effects with string formatting -#### TL;DR Being aware that string formatting may lead to calling existing functions means watching out for possible deadlocks and other data races. diff --git a/prompts/skills/100-go-mistakes/references/mistake-69-creating-data-races-with-append.md b/prompts/skills/100-go-mistakes/references/mistake-69-creating-data-races-with-append.md index f1d411b..fbe6c14 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-69-creating-data-races-with-append.md +++ b/prompts/skills/100-go-mistakes/references/mistake-69-creating-data-races-with-append.md @@ -1,6 +1,5 @@ # Mistake #69: Creating data races with append -#### TL;DR Calling `append` isn’t always data-race-free; hence, it shouldn’t be used concurrently on a shared slice. diff --git a/prompts/skills/100-go-mistakes/references/mistake-70-using-mutexes-inaccurately-with-slices-and-maps.md b/prompts/skills/100-go-mistakes/references/mistake-70-using-mutexes-inaccurately-with-slices-and-maps.md index f764b59..466e1ca 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-70-using-mutexes-inaccurately-with-slices-and-maps.md +++ b/prompts/skills/100-go-mistakes/references/mistake-70-using-mutexes-inaccurately-with-slices-and-maps.md @@ -1,6 +1,5 @@ # Mistake #70: Using mutexes inaccurately with slices and maps -#### TL;DR Remembering that slices and maps are pointers can prevent common data races. diff --git a/prompts/skills/100-go-mistakes/references/mistake-71-misusing-syncwaitgroup.md b/prompts/skills/100-go-mistakes/references/mistake-71-misusing-syncwaitgroup.md index b9f897c..c90a061 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-71-misusing-syncwaitgroup.md +++ b/prompts/skills/100-go-mistakes/references/mistake-71-misusing-syncwaitgroup.md @@ -1,6 +1,5 @@ # Mistake #71: Misusing sync.WaitGroup -#### TL;DR Call `wg.Add` before spinning up goroutines, not inside them. Calling `Add` inside a goroutine introduces a race with `Wait`. diff --git a/prompts/skills/100-go-mistakes/references/mistake-72-forgetting-about-synccond.md b/prompts/skills/100-go-mistakes/references/mistake-72-forgetting-about-synccond.md index 6920862..edd6186 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-72-forgetting-about-synccond.md +++ b/prompts/skills/100-go-mistakes/references/mistake-72-forgetting-about-synccond.md @@ -1,6 +1,5 @@ # Mistake #72: Forgetting about sync.Cond -#### TL;DR Use `sync.Cond` to send notifications to multiple goroutines. It provides `Signal` (wake one goroutine) and `Broadcast` (wake all waiting goroutines), which can be more efficient than channel-based alternatives when broadcasting. diff --git a/prompts/skills/100-go-mistakes/references/mistake-73-not-using-errgroup.md b/prompts/skills/100-go-mistakes/references/mistake-73-not-using-errgroup.md index 5b53c0f..d74640f 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-73-not-using-errgroup.md +++ b/prompts/skills/100-go-mistakes/references/mistake-73-not-using-errgroup.md @@ -1,6 +1,5 @@ # Mistake #73: Not using errgroup -#### TL;DR Use `errgroup` to synchronize a group of goroutines and handle errors, as well as shared context cancellation. It simplifies patterns involving multiple concurrent operations that can fail. diff --git a/prompts/skills/100-go-mistakes/references/mistake-74-copying-a-sync-type.md b/prompts/skills/100-go-mistakes/references/mistake-74-copying-a-sync-type.md index 6862867..2409895 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-74-copying-a-sync-type.md +++ b/prompts/skills/100-go-mistakes/references/mistake-74-copying-a-sync-type.md @@ -1,6 +1,5 @@ # Mistake #74: Copying a sync type -#### TL;DR Types from the `sync` package should never be copied. This applies to `sync.Mutex`, `sync.WaitGroup`, `sync.Cond`, and the other types. Use pointers to share them. diff --git a/prompts/skills/100-go-mistakes/references/mistake-75-providing-a-wrong-time-duration.md b/prompts/skills/100-go-mistakes/references/mistake-75-providing-a-wrong-time-duration.md index 2755efc..8eadb22 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-75-providing-a-wrong-time-duration.md +++ b/prompts/skills/100-go-mistakes/references/mistake-75-providing-a-wrong-time-duration.md @@ -1,6 +1,5 @@ # Mistake #75: Providing a wrong time duration -#### TL;DR Remain cautious with functions accepting a `time.Duration`. Even though passing an integer is allowed, strive to use the time API to prevent any possible confusion. diff --git a/prompts/skills/100-go-mistakes/references/mistake-76-timeafter-and-memory-leaks.md b/prompts/skills/100-go-mistakes/references/mistake-76-timeafter-and-memory-leaks.md index 6a0141f..ffb457e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-76-timeafter-and-memory-leaks.md +++ b/prompts/skills/100-go-mistakes/references/mistake-76-timeafter-and-memory-leaks.md @@ -1,6 +1,5 @@ # Mistake #76: time.After and memory leaks -#### TL;DR Avoid using `time.After` in loops or repeated calls; it creates a new channel each time that won't be GC'd until the timer fires. Use `time.NewTimer` instead and call `Stop` when done. diff --git a/prompts/skills/100-go-mistakes/references/mistake-79-not-closing-transient-resources-http-body-sqlrows-and-osfile.md b/prompts/skills/100-go-mistakes/references/mistake-79-not-closing-transient-resources-http-body-sqlrows-and-osfile.md index 8ec7653..046f17e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-79-not-closing-transient-resources-http-body-sqlrows-and-osfile.md +++ b/prompts/skills/100-go-mistakes/references/mistake-79-not-closing-transient-resources-http-body-sqlrows-and-osfile.md @@ -1,6 +1,5 @@ # Mistake #79: Not closing transient resources (HTTP body, sql.Rows, and os.File) -#### TL;DR Always close transient resources like HTTP response bodies, `sql.Rows`, and `os.File` to avoid leaks. Use `defer` after checking for errors. diff --git a/prompts/skills/100-go-mistakes/references/mistake-80-forgetting-the-return-statement-after-replying-to-an-http-request.md b/prompts/skills/100-go-mistakes/references/mistake-80-forgetting-the-return-statement-after-replying-to-an-http-request.md index 30447f9..c2676ed 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-80-forgetting-the-return-statement-after-replying-to-an-http-request.md +++ b/prompts/skills/100-go-mistakes/references/mistake-80-forgetting-the-return-statement-after-replying-to-an-http-request.md @@ -1,6 +1,5 @@ # Mistake #80: Forgetting the return statement after replying to an HTTP request -#### TL;DR To avoid unexpected behaviors in HTTP handler implementations, make sure you don’t miss the `return` statement if you want a handler to stop after `http.Error`. diff --git a/prompts/skills/100-go-mistakes/references/mistake-81-using-the-default-http-client-and-server.md b/prompts/skills/100-go-mistakes/references/mistake-81-using-the-default-http-client-and-server.md index b0ec2f7..a1a2d4e 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-81-using-the-default-http-client-and-server.md +++ b/prompts/skills/100-go-mistakes/references/mistake-81-using-the-default-http-client-and-server.md @@ -1,6 +1,5 @@ # Mistake #81: Using the default HTTP client and server -#### TL;DR For production-grade applications, don’t use the default HTTP client and server implementations. These implementations are missing timeouts and behaviors that should be mandatory in production. diff --git a/prompts/skills/100-go-mistakes/references/mistake-82-not-categorizing-tests-build-tags-environment-variables-and-short-mode.md b/prompts/skills/100-go-mistakes/references/mistake-82-not-categorizing-tests-build-tags-environment-variables-and-short-mode.md index 3ca678f..d2b4bfa 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-82-not-categorizing-tests-build-tags-environment-variables-and-short-mode.md +++ b/prompts/skills/100-go-mistakes/references/mistake-82-not-categorizing-tests-build-tags-environment-variables-and-short-mode.md @@ -1,6 +1,5 @@ # Mistake #82: Not categorizing tests (build tags, environment variables, and short mode) -#### TL;DR Categorizing tests using build flags, environment variables, or short mode makes the testing process more efficient. You can create test categories using build flags or environment variables (for example, unit versus integration tests) and differentiate short from long-running tests to decide which kinds of tests to execute. diff --git a/prompts/skills/100-go-mistakes/references/mistake-83-not-enabling-the-race-flag.md b/prompts/skills/100-go-mistakes/references/mistake-83-not-enabling-the-race-flag.md index d3aa113..2066d8c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-83-not-enabling-the-race-flag.md +++ b/prompts/skills/100-go-mistakes/references/mistake-83-not-enabling-the-race-flag.md @@ -1,6 +1,5 @@ # Mistake #83: Not enabling the race flag -#### TL;DR Enabling the `-race` flag is highly recommended when writing concurrent applications. Doing so allows you to catch potential data races that can lead to software bugs. diff --git a/prompts/skills/100-go-mistakes/references/mistake-84-not-using-test-execution-modes-parallel-and-shuffle.md b/prompts/skills/100-go-mistakes/references/mistake-84-not-using-test-execution-modes-parallel-and-shuffle.md index 31c968a..ec9134c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-84-not-using-test-execution-modes-parallel-and-shuffle.md +++ b/prompts/skills/100-go-mistakes/references/mistake-84-not-using-test-execution-modes-parallel-and-shuffle.md @@ -1,5 +1,4 @@ # Mistake #84: Not using test execution modes (parallel and shuffle) -#### TL;DR Using the `-parallel` flag is an efficient way to speed up tests, especially long-running ones. Use the `-shuffle` flag to help ensure that a test suite doesn’t rely on wrong assumptions that could hide bugs. diff --git a/prompts/skills/100-go-mistakes/references/mistake-85-not-using-table-driven-tests.md b/prompts/skills/100-go-mistakes/references/mistake-85-not-using-table-driven-tests.md index f2fdfd2..739d0ba 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-85-not-using-table-driven-tests.md +++ b/prompts/skills/100-go-mistakes/references/mistake-85-not-using-table-driven-tests.md @@ -1,6 +1,5 @@ # Mistake #85: Not using table-driven tests -#### TL;DR Table-driven tests are an efficient way to group a set of similar tests to prevent code duplication and make future updates easier to handle. diff --git a/prompts/skills/100-go-mistakes/references/mistake-86-sleeping-in-unit-tests.md b/prompts/skills/100-go-mistakes/references/mistake-86-sleeping-in-unit-tests.md index 879f7c3..1f0d91f 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-86-sleeping-in-unit-tests.md +++ b/prompts/skills/100-go-mistakes/references/mistake-86-sleeping-in-unit-tests.md @@ -1,6 +1,5 @@ # Mistake #86: Sleeping in unit tests -#### TL;DR Avoid sleeps using synchronization to make a test less flaky and more robust. If synchronization isn’t possible, consider a retry approach. diff --git a/prompts/skills/100-go-mistakes/references/mistake-87-not-dealing-with-the-time-api-efficiently.md b/prompts/skills/100-go-mistakes/references/mistake-87-not-dealing-with-the-time-api-efficiently.md index 738e54e..11b1865 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-87-not-dealing-with-the-time-api-efficiently.md +++ b/prompts/skills/100-go-mistakes/references/mistake-87-not-dealing-with-the-time-api-efficiently.md @@ -1,6 +1,5 @@ # Mistake #87: Not dealing with the time API efficiently -#### TL;DR Understanding how to deal with functions using the time API is another way to make a test less flaky. You can use standard techniques such as handling the time as part of a hidden dependency or asking clients to provide it. diff --git a/prompts/skills/100-go-mistakes/references/mistake-88-not-using-testing-utility-packages-httptest-and-iotest.md b/prompts/skills/100-go-mistakes/references/mistake-88-not-using-testing-utility-packages-httptest-and-iotest.md index 5c237b7..caed312 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-88-not-using-testing-utility-packages-httptest-and-iotest.md +++ b/prompts/skills/100-go-mistakes/references/mistake-88-not-using-testing-utility-packages-httptest-and-iotest.md @@ -1,6 +1,5 @@ # Mistake #88: Not using testing utility packages (httptest and iotest) -#### TL;DR Use the `httptest` package for testing HTTP clients and servers, and the `iotest` package for testing `io.Reader` implementations and error tolerance. diff --git a/prompts/skills/100-go-mistakes/references/mistake-89-writing-inaccurate-benchmarks.md b/prompts/skills/100-go-mistakes/references/mistake-89-writing-inaccurate-benchmarks.md index d711c92..67a2b2c 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-89-writing-inaccurate-benchmarks.md +++ b/prompts/skills/100-go-mistakes/references/mistake-89-writing-inaccurate-benchmarks.md @@ -1,6 +1,5 @@ # Mistake #89: Writing inaccurate benchmarks -#### TL;DR Regarding benchmarks: diff --git a/prompts/skills/100-go-mistakes/references/mistake-92-writing-concurrent-code-that-leads-to-false-sharing.md b/prompts/skills/100-go-mistakes/references/mistake-92-writing-concurrent-code-that-leads-to-false-sharing.md index 38c1c89..aca6de4 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-92-writing-concurrent-code-that-leads-to-false-sharing.md +++ b/prompts/skills/100-go-mistakes/references/mistake-92-writing-concurrent-code-that-leads-to-false-sharing.md @@ -1,6 +1,5 @@ # Mistake #92: Writing concurrent code that leads to false sharing -#### TL;DR Knowing that lower levels of CPU caches aren’t shared across all the cores helps avoid performance-degrading patterns such as false sharing while writing concurrency code. Sharing memory is an illusion. diff --git a/prompts/skills/100-go-mistakes/references/mistake-93-not-taking-into-account-instruction-level-parallelism.md b/prompts/skills/100-go-mistakes/references/mistake-93-not-taking-into-account-instruction-level-parallelism.md index ce4cafc..42704df 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-93-not-taking-into-account-instruction-level-parallelism.md +++ b/prompts/skills/100-go-mistakes/references/mistake-93-not-taking-into-account-instruction-level-parallelism.md @@ -1,6 +1,5 @@ # Mistake #93: Not taking into account instruction-level parallelism -#### TL;DR Use ILP to optimize specific parts of your code to allow a CPU to execute as many parallel instructions as possible. Identifying data hazards is one of the main steps. diff --git a/prompts/skills/100-go-mistakes/references/mistake-94-not-being-aware-of-data-alignment.md b/prompts/skills/100-go-mistakes/references/mistake-94-not-being-aware-of-data-alignment.md index f2ff22c..bf539b6 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-94-not-being-aware-of-data-alignment.md +++ b/prompts/skills/100-go-mistakes/references/mistake-94-not-being-aware-of-data-alignment.md @@ -1,6 +1,5 @@ # Mistake #94: Not being aware of data alignment -#### TL;DR You can avoid common mistakes by remembering that in Go, basic types are aligned with their own size. For example, keep in mind that reorganizing the fields of a struct by size in descending order can lead to more compact structs (less memory allocation and potentially a better spatial locality). diff --git a/prompts/skills/100-go-mistakes/references/mistake-95-not-understanding-stack-vs-heap.md b/prompts/skills/100-go-mistakes/references/mistake-95-not-understanding-stack-vs-heap.md index ad2d02d..76feb77 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-95-not-understanding-stack-vs-heap.md +++ b/prompts/skills/100-go-mistakes/references/mistake-95-not-understanding-stack-vs-heap.md @@ -1,6 +1,5 @@ # Mistake #95: Not understanding stack vs. heap -#### TL;DR Understanding the fundamental differences between heap and stack should also be part of your core knowledge when optimizing a Go application. Stack allocations are almost free, whereas heap allocations are slower and rely on the GC to clean the memory. diff --git a/prompts/skills/100-go-mistakes/references/mistake-96-not-knowing-how-to-reduce-allocations.md b/prompts/skills/100-go-mistakes/references/mistake-96-not-knowing-how-to-reduce-allocations.md index 10a478e..cab36fa 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-96-not-knowing-how-to-reduce-allocations.md +++ b/prompts/skills/100-go-mistakes/references/mistake-96-not-knowing-how-to-reduce-allocations.md @@ -1,6 +1,5 @@ # Mistake #96: Not knowing how to reduce allocations -#### TL;DR Reducing allocations improves performance by decreasing GC pressure. Techniques include API changes to accept pre-allocated buffers, leveraging compiler optimizations, and using `sync.Pool` for reusable objects. diff --git a/prompts/skills/100-go-mistakes/references/mistake-97-not-relying-on-inlining.md b/prompts/skills/100-go-mistakes/references/mistake-97-not-relying-on-inlining.md index fefcb97..e231d68 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-97-not-relying-on-inlining.md +++ b/prompts/skills/100-go-mistakes/references/mistake-97-not-relying-on-inlining.md @@ -1,5 +1,4 @@ # Mistake #97: Not relying on inlining -#### TL;DR Use the fast-path inlining technique to efficiently reduce the amortized time to call a function. diff --git a/prompts/skills/100-go-mistakes/references/mistake-98-not-using-go-diagnostics-tooling.md b/prompts/skills/100-go-mistakes/references/mistake-98-not-using-go-diagnostics-tooling.md index 4002313..172c854 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-98-not-using-go-diagnostics-tooling.md +++ b/prompts/skills/100-go-mistakes/references/mistake-98-not-using-go-diagnostics-tooling.md @@ -1,6 +1,5 @@ # Mistake #98: Not using Go diagnostics tooling -#### TL;DR Rely on profiling and the execution tracer to understand how an application performs and the parts to optimize. diff --git a/prompts/skills/100-go-mistakes/references/mistake-99-not-understanding-how-the-gc-works.md b/prompts/skills/100-go-mistakes/references/mistake-99-not-understanding-how-the-gc-works.md index af64289..279db6b 100644 --- a/prompts/skills/100-go-mistakes/references/mistake-99-not-understanding-how-the-gc-works.md +++ b/prompts/skills/100-go-mistakes/references/mistake-99-not-understanding-how-the-gc-works.md @@ -1,6 +1,5 @@ # Mistake #99: Not understanding how the GC works -#### TL;DR Understanding the Go garbage collector helps write more efficient applications. The GC uses a concurrent, tri-color mark-and-sweep algorithm. Reducing heap allocations and understanding the `GOGC` tuning parameter are key. |