restore code tips

Author: FranciscoMoretti

app/tag-data.json

@@ -1,6 +1,7 @@
 {
   "JavaScript": 6,
   "Debugging": 2,
+  "Code Tips": 34,
   "Best Practices": 8,
   "Next.js": 19,
   "TypeScript": 3,

data/blog/avoid-hasty-abstractions-aha.md

@@ -0,0 +1,91 @@
+---
+alias: AHA Principle, Avoiding Hasty Abstractions, Moist Programming
+category: General
+
+publish: true
+slug: avoid-hasty-abstractions-aha
+
+title: Avoid Hasty Abstractions (AHA)
+summary: Prefer duplication over the wrong abstraction. Avoid rushing into creating abstractions without a clear understanding of the problem domain.
+draft: false
+tags: ['Code Tips']
+date: 2023-06-23
+---
+
+## Usage
+
+### 📝 Guideline
+
+**Avoid Hasty Abstractions**: Prefer duplication over the wrong abstraction.
+
+Avoid rushing into creating abstractions without a clear understanding of the problem domain. It is better to tolerate duplication initially than to create premature or incorrect abstractions.
+
+### 🛠️ How to Apply
+
+- **Prefer duplication**: If you're unsure about the correct abstraction, it's better to have duplicated code temporarily until you fully understand the commonalities and requirements for abstraction. 📊
+- **Identify commonalities**: Look for patterns and similarities in the duplicated code. When you notice parts that can be generalized, you'll be in a better position to provide meaningful abstractions. 🧩
+- **Consider future requirements**: Instead of prematurely optimizing for performance or designing the "perfect" API, focus on code that can easily adapt to future changes. 🔮
+- **Avoid premature abstractions**: If you abstract too early, you might end up with complex code that's difficult to maintain. Wait until you have a good understanding of the use cases before creating abstractions. 🚧
+- **Mindful Abstraction**: When the commonalities are clear, it's the right time to create abstractions. Abstract out the shared functionality into functions or modules that accurately capture the essence of the problem. 🌤️
+
+## Pros and Cons
+
+### 👍 Pros
+
+- **Increased Clarity**: Duplicating code initially allows you to gain a deeper understanding of the problem, leading to clearer and more concise abstractions. 🔍
+- **Flexible Adaptation**: Delaying abstractions until commonalities are well-understood enables easier adaptation to future changes in requirements or use cases. 🔄
+- **Accurate abstractions**: By avoiding hasty abstractions, you ensure that your abstractions accurately represent the underlying problem domain. 🎯
+
+### 👎 Cons
+
+- **Code duplication**: Delaying abstractions may result in some code duplication, which can be seen as a drawback.♻️
+- **Maintenance overhead**: Duplicated code may require updates in multiple places if changes are needed, leading to increased maintenance overhead. 🪨
+
+## Examples
+
+### ❌ Bad
+
+```typescript
+// Bad Example: Hasty Abstraction that don't provide much value and forces one item per operation
+function performOperation(items: Item[], operation: string): void {
+  for (const item of items) {
+    performCustomOperation(item, operation)
+  }
+}
+
+function performCustomOperation(item: Item, operation: string): void {
+  if (operation === 'operation1') {
+    // Custom operation 1
+  } else if (operation === 'operation2') {
+    // Custom operation 2
+  }
+  // More operations...
+}
+```
+
+### ✅ Good
+
+```typescript
+// Good Example: Avoid Hasty Abstraction
+
+function performOperation(items: Item[], operation: string): void {
+  if (operation === 'operation1') {
+    for (const item of items) {
+      // Custom operation 1 logic
+    }
+  } else if (operation === 'operation2') {
+    for (const item of items) {
+      // Custom operation 2 logic
+    }
+  }
+  // More operations...
+}
+```
+
+## References
+
+### 🔀 Related principles
+
+- **Optimize for change first**: This principle complements AHA by emphasizing the need for flexibility in the face of evolving requirements. 🔧
+- [**Don't Repeat Yourself (DRY)**](/blog/dont-repeat-yourself-dry): While AHA suggests temporary duplication, DRY focuses on removing duplication through well-designed abstractions. 🔄
+- [**Write Everything Twice (WET)**](/blog/write-everything-twice-wet): AHA encourages careful consideration of abstractions, which aligns with the idea of avoiding unnecessary complexity promoted by WET. ♻️

data/blog/avoid-mental-mapping.md

@@ -0,0 +1,64 @@
+---
+title: Avoid Mental Mapping
+
+summary: Master the technique of avoiding mental mapping in your code. Enhance readability and eliminate confusion with explicit variable naming.
+category: Variables
+slug: avoid-mental-mapping
+draft: false
+tags: ['Code Tips']
+date: 2023-05-22
+---
+
+## Usage
+
+### 📝 Guideline
+
+**Avoid Variable Mental Mapping**: Use explicit names for variables instead of using an alias. A single-letter name is just a placeholder for the reader to map into the actual concept, and this can lead to confusion.
+
+Mental mapping occurs when a reader or reviewer needs to decipher the meaning of a variable by inferring its purpose from its context. By using clear and descriptive names, you can eliminate mental mapping and make your code more readable and maintainable.
+
+### 🛠️ How to Apply
+
+- Use meaningful variable names that accurately describe the purpose and content of the data. 📌
+- Avoid using single-letter variables unless they are widely recognized and have a clear purpose. 🚫
+- Refactor code to replace ambiguous or confusing variable names with more descriptive ones. 🔁
+
+## Pros and Cons
+
+### 👍 Pros
+
+- **Improved Code Comprehension**: Clear and explicit variable names enhance code readability and make it easier to understand the purpose of each variable. 📚
+- **Reduced Mental Effort**: Eliminating mental mapping reduces cognitive load and allows developers to focus on the logic and functionality of the code. 💡
+
+### 👎 Cons
+
+- **Increased Code Length**: Descriptive variable names can make the code longer, potentially affecting readability in some cases. 📏
+- **Naming Challenges**: Finding the right balance between concise and descriptive variable names can be challenging, requiring careful consideration. 🔍
+
+## Examples
+
+### ❌ Bad
+
+```typescript
+// Bad
+const x = 5 // What does 'x' represent?
+const y = 10 // And what about 'y'?
+const result = x * y // No context, mental mapping required
+```
+
+### ✅ Good
+
+```typescript
+// Good
+const width = 5 // Descriptive name for the width of a shape
+const height = 10 // Descriptive name for the height of a shape
+const area = width * height // Clear context, no mental mapping needed
+```
+
+## References
+
+### 🔀 Related principles
+
+- **Avoid Abbreviations**: Abbreviating variable names can increase mental mapping. 🚫
+- **Use Descriptive Naming**: Clear and meaningful names provide better understanding. 📚
+- **Avoid Magic Numbers**: Replace unclear numeric values with named constants. 🔢

data/blog/avoid-negative-conditionals.md

@@ -0,0 +1,67 @@
+---
+title: Avoid Negative Conditionals
+
+draft: false
+tags: ['Code Tips']
+date: 2023-06-05
+summary: Negatives are harder to understand. Conditional functions should be expressed as positives every time.
+category: General
+slug: avoid-negative-conditionals
+---
+
+## Usage
+
+### 📝 Guideline
+
+**Avoid Negative Conditionals**: Negatives are harder to understand. Conditional functions should be expressed as positives.
+
+Conditional functions that use negative statements can make the code harder to read and comprehend. By expressing conditional logic in positive terms, you can enhance code readability and make it easier to understand the intended behavior.
+
+### 🛠️ How to Apply
+
+- **Use positive conditionals**: Instead of checking for the absence of a condition, check for its presence. This can make the code more straightforward and easier to follow. 🐣
+- **Use descriptive variable and function names**: Choose names that clearly convey the purpose of the condition, making the code more self-explanatory. 📛
+- **Invert conditions sparingly**: If inverting a condition improves code clarity, do so sparingly. Be mindful of the potential impact on code readability. 🤏
+- **Avoid using "not" in function names**: Function names should not include the word "not" as it can make the code less intuitive. Instead, utilize the "not" Boolean operator with the function call itself to express negation. ⛔️
+
+## Pros and Cons
+
+### 👍 Pros
+
+- **Improved readability**: Positive conditionals make the code easier to understand, as they express the desired behavior directly. 😃
+- **Reduced cognitive load**: Avoiding negative conditionals helps reduce mental strain and makes it easier to reason about code. 🧠
+
+### 👎 Cons
+
+- **Increased verbosity**: Positive conditionals may require additional code or conditions to handle negative cases, potentially leading to increased verbosity. 💬
+- **Risk of error**: If the positive conditionals are not written accurately, there is a possibility of introducing logic errors. ❌
+
+## Examples
+
+### ❌ Bad
+
+```typescript
+if (!isNotLoggedIn) {
+  // Do something if logged in
+} else {
+  // Do something if not logged in
+}
+```
+
+### ✅ Good
+
+```typescript
+if (isLoggedIn) {
+  // Do something if logged in
+} else {
+  // Do something if not logged in
+}
+```
+
+## References
+
+### 🔀 Related principles
+
+- **Positive Language Principle**: Using positive language throughout the codebase enhances readability and clarity. 🌟
+- **Use Intention-Revealing Names**: Choosing descriptive names for variables and functions helps eliminate the need for negative conditionals by clearly indicating the intention behind the code. 📛
+- **Guard Clause Principle**: Utilizing guard clauses helps improve code readability by handling special cases early on and reducing nesting depth. 🚧

data/blog/avoid-side-effects.md

@@ -0,0 +1,76 @@
+---
+title: Avoid side effects
+alias: Side Effect Prevention, Side Effect Minimization, Side Effect Avoidance
+
+draft: false
+tags: ['Code Tips']
+date: 2023-06-12
+summary: Improve code reliability by avoiding side effects. Minimize hidden consequences, enhance predictability, and simplify testing.
+category: Functions
+slug: avoid-side-effects
+---
+
+## Usage
+
+### 📝 Guideline
+
+**Avoid Side Effects**: Minimize or eliminate code that modifies state or produces non-obvious consequences.
+
+Code that produces unexpected changes to the system's state or has hidden consequences can be difficult to reason about and debug. By avoiding side effects, you can create code that is more predictable, easier to test, and less prone to bugs.
+
+### 🛠️ How to Apply
+
+- **Immutability**: Favor immutability whenever possible to prevent accidental modifications of shared data. 🚫
+- **Pure Functions**: Write pure functions that only depend on their input and produce consistent output, without modifying external state. 🧪
+- **Avoid Global State**: Minimize the use of global variables or shared state, as they can lead to hidden dependencies and unintended side effects. 🌍
+
+## Pros and Cons
+
+### 👍 Pros
+
+- **Predictability**: Code without side effects is easier to understand and predict because its behavior is more explicit and deterministic. 🎯
+- **Testability**: Side-effect-free code is easier to test, as it can be isolated and its behavior can be verified without the need for complex setup or mocking. 🧪
+- **Concurrency**: Code with fewer side effects is generally more amenable to concurrent or parallel execution, as it avoids shared mutable state and potential race conditions. 🏃‍♂️
+
+### 👎 Cons
+
+- **Performance impact**: Avoiding side effects may introduce additional data copies or indirection, impacting performance slightly. However, improved maintainability and reliability often outweigh this trade-off. 🐢
+- **Integration challenges**: When working with legacy codebases or third-party libraries that heavily rely on side effects, adopting a side effect free approach can be challenging. 🚧
+
+## Examples
+
+### ❌ Bad
+
+```typescript
+// Bad example: Function with side effects
+let counter = 0
+
+function incrementCounter() {
+  counter++
+}
+
+incrementCounter()
+console.log(counter) // Output: 1
+```
+
+### ✅ Good
+
+```typescript
+// Good example: Pure function without side effects
+function incrementCounter(counter: number): number {
+  return counter + 1
+}
+
+let counter = 0
+counter = incrementCounter(counter)
+console.log(counter) // Output: 1
+```
+
+## References
+
+### 🔀 Related principles
+
+- **Separation of Concerns**: Avoiding side effects is closely related to the principle of separation of concerns, as it promotes modular and decoupled code by isolating state manipulation. 🧩
+- **Immutable Data**: The concept of immutability complements side effect prevention by emphasizing the use of unmodifiable data structures to prevent unintended changes. 🔒
+- **Pure Functions**: Side effect avoidance aligns with the use of pure functions, which have no side effects and produce consistent results based solely on their input. 🧪
+- **Functional Composition**: Pure functions without side effects can be easily composed together to create larger and more complex functions. This encourages modular and reusable code. 🔀