functional-patterns

Files (1)

• SKILL.md

SKILL.md (first lines)

# Functional Patterns

When invoked, review the specified code for imperative loops that transform, filter, or aggregate data. Refactor into functional data pipelines using the language's built-in higher-order functions. The goal is declarative code that clearly states *what* happens to the data, with the *how* handled by well-known primitives.

If the user has not specified a scope (file or directory), ask them which file or directory to focus on before proceeding.

## Core Rules

1. **Use `filter` to select elements matching a condition.** Replaces loops with `if` + `append`. The predicate function declares which elements to keep.

2. **Use `map` to transform each element.** Replaces loops that build a new list of transformed items. The mapper function declares what each element becomes.

3. **Use `reduce`/`fold` to aggregate a collection into a single value.** Replaces loops with an accumulator variable. The reducer function declares how elements combine.

4. **Use `sort` with a comparator function.** Replaces manual sorting loops or insertion-based ordering. The comparator declares the ordering criterion.

5. **Use `slice`/`take` to limit results.** Replaces counter-based early exits from loops.

6. **Chain operations into data pipelines.** Order the chain logically:
   - **Filter first** -- reduce data volume early to avoid unnecessary work.
   - **Map second** -- transform remaining elements into the shape you need.
   - **Sort third** -- order the transformed results.
   - **Slice last** -- take only what you need from the sorted results.

7. **Use lambda/arrow functions for short predicates and transformers.** A one-line lambda is more readable inline than a named function in a different location. Extract to a named function only when the logic is complex enough to benefit from a descriptive name or when it is reused.

8. **Do not force functional style where it does not fit.** Side-effectful operations -- database writes, API calls, file I/O, sending notifications -- should remain imperative. Functional pipelines are for data transformation, not orchestration. If a loop's body performs side effects on each iteration, it is not a candidate for `map`.

9. **Watch for performance implications.** Chaining `filter`, `map`, and `sort` creates multiple passes over the data. For small-to-medium collections (typical business logic), this is negligible. For very large datasets or hot paths, a single-pass loop may be warranted -- add a comment explaining why the imperative form is intentional.

10. **Prefer pure functions.** Functions in the pipeline should take inputs and return outputs without modifying external state. This makes each step independently understandable and testable.

## Language-Specific Idioms

Adapt to the language of the user's codebase:

- **JavaScript/TypeScript:** Method chaining on arrays -- `.filter().map().sort().slice()`. Use arrow functions.
- **Python:** List comprehensions for simple filter+map (`[x.name for x in items if x.active]`). Use `sorted()` with `key=`. Use `itertools` for advanced patterns. Generator expressions for lazy evaluation.
- **Java:** Streams API -- `stream().filter().map().sorted().limit().collect()`.
- **C#:** LINQ -- `.Where().Select().OrderBy().Take()`.
- **Rust:** Iterator chains -- `.iter().filter().map().sorted().take().collect()`.
- **Go:** No built-in higher-order functions on slices (pre-generics). Use `slices` package or simple loops. Do not force functional style in Go -- idiomatic Go uses explicit loops.

## Procedure

1. **Identify candidate loops.** Look for `for`/`while` loops that:
   - Build up a result list by appending conditionally (→ filter).
   - Build a new list by transforming each element (→ map).
   - Compute a single aggregate value from a collection (→ reduce).
   - Sort elements by comparison (→ sort).
   - Stop after N results (→ slice/take).
   - Combine two or more of the above.

2. **Classify each loop by purpose.** A single loop often combines filtering and mapping. Decompose it into its constituent operations.

3. **Rewrite using higher-order functions.** Chain them in pipeline order. Use the language's idiomatic syntax.

4. **Preserve behavior.** The refactored code must produce identical results. Pay attention to:
   - Order of elements (filter preserves order, sort changes it).
   - Handling of empty collections.
   - Side effects in the original loop body -- if present, the loop is not a candidate for pure functional refactoring.

5. **Present changes** with a brief explanation of what each pipeline step does.

---

## Examples

### Example A: Filter + Map Pipeline

An imperative loop that selects employees and extracts their names:

**Before:**

```typescript
function getSeniorEngineerNames(employees: Employee[]): string[] {
    const result: string[] = [];

    for (let i = 0; i < employees.length; i++) {
        const emp = employees[i];
        if (emp.department === "Engineering") {
            if (emp.yearsOfService > 5) {
                result.push(emp.firstName + " " + emp.lastName);
            }
        }
    }

    return result;
}
```

The loop mixes three concerns: iterating, filtering, and transforming. The nested `if` statements obscure the intent.

**After:**

```typescript
function getSeniorEngineerNames(employees: Employee[]): string[] {
    return employees
        .filter(emp => emp.department === "Engineering" && emp.yearsOfService > 5)
        .map(emp => `${emp.firstName} ${emp.lastName}`);
}
```

The pipeline reads as a declaration: "from all employees, keep the senior engineers, then extract their full names." Each step does one thing. No index variable, no temporary array, no nested conditions.

---

### Example B: Reduce for Aggregation

A loop that computes a running balance from a list of transactions:

**Before:**

```python
def calculate_balance(transactions):
    balance = 0
    overdraft_count = 0

    for txn in transactions:

From nitrictech/skills, MIT.

More from nitrictech/skills