#!/bin/bash
# syntax-snob.sh - A passive-aggressive pre-commit hook
# Place in .git/hooks/pre-commit and make executable

# Configuration - customize these for your project
FORMATTER="black"  # Python formatter
LINTER="flake8"     # Python linter
MAX_LINE_LENGTH=88
AUTO_FIX=true      # Automatically fix what you can

# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo -e "${YELLOW}🔍 Syntax Snob is checking your code...${NC}"

# Get staged Python files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.py$')

if [ -z "$FILES" ]; then
    echo "No Python files to check. Skipping."
    exit 0
fi

ERRORS=0

for file in $FILES; do
    echo "\nChecking: $file"
    
    # Run formatter if enabled
    if [ "$AUTO_FIX" = true ] && command -v $FORMATTER &> /dev/null; then
        echo "  Formatting with $FORMATTER..."
        $FORMATTER --line-length $MAX_LINE_LENGTH $file
        git add $file
    fi
    
    # Run linter
    if command -v $LINTER &> /dev/null; then
        echo "  Linting with $LINTER..."
        if ! $LINTER --max-line-length=$MAX_LINE_LENGTH $file; then
            echo -e "${RED}  ✗ Linting issues found${NC}"
            ERRORS=$((ERRORS + 1))
        else
            echo -e "${GREEN}  ✓ Code style approved${NC}"
        fi
    fi
    
    # Check for trailing whitespace
    if grep -n "[[:blank:]]$" $file; then
        echo -e "${RED}  ✗ Trailing whitespace detected${NC}"
        if [ "$AUTO_FIX" = true ]; then
            sed -i 's/[[:space:]]*$//' $file
            git add $file
            echo "  Fixed trailing whitespace"
        fi
        ERRORS=$((ERRORS + 1))
    fi

done

if [ $ERRORS -gt 0 ] && [ "$AUTO_FIX" = false ]; then
    echo -e "\n${RED}❌ Syntax Snob blocked commit: $ERRORS issue(s) found${NC}"
    echo "Set AUTO_FIX=true or fix manually and try again."
    exit 1
else
    echo -e "\n${GREEN}✅ Syntax Snob approved! No holy wars today.${NC}"
    exit 0
fi

The Problem: When Code Review Becomes Performance Art

Let's be honest: most code style debates have all the intellectual rigor of arguing about whether toilet paper should roll over or under. Yet somehow, these discussions consume more developer hours than actual feature development. The problem isn't that style guides exist—consistency has value—but that we've collectively decided to treat personal preferences as objective truths.

Consider the typical scenario: You submit a pull request. It adds a critical security fix. The first comment? "Trailing whitespace on line 42." The second? "Shouldn't this be a ternary operator?" By comment seven, you're debating whether 'i' or 'index' is the morally superior loop variable name while the actual security vulnerability sits there, waving politely, completely ignored.

The absurdity reaches peak performance when you realize most of these 'violations' could be automatically fixed by tools that have existed for decades. Yet here we are, in 2024, having emotional breakdowns about spaces vs. tabs like it's 1992 and we're choosing our first AOL screenname. The time wasted isn't just about the minutes spent adding semicolons—it's about the cognitive load, the team friction, and the sheer comedy of watching grown professionals argue bracket placement with the intensity of medieval theologians debating how many angels can dance on the head of a pin.

The Solution: Automated Passive Aggression

I built Syntax Snob to solve this existential crisis of developer productivity. The premise is beautifully simple: if reviewers are going to nitpick trivial formatting issues, let's automate both the fixing and the emotional labor of being judged for them.

Syntax Snob is a pre-commit hook that scans your code for 'violations' of whatever arbitrary style rules your team has decided are worth emotional investment. But instead of just fixing them silently like a sensible tool, it generates dramatic, sarcastic commentary for each change. Did you forget a semicolon? Syntax Snob will add it while commenting "Added the sacred semicolon that separates civilized code from barbarism." Trailing whitespace? "Removed the ghost spaces that were haunting our codebase."

The real innovation, though, is that Syntax Snob can be configured to match each reviewer's personal preferences. Karen from backend prefers K&R style brackets? Syntax Snob will reformat everything to her liking before she even sees the PR. Dave from DevOps loses his mind over double quotes in JSON? Syntax Snob swaps them for singles. The tool essentially performs emotional labor at scale, pre-emptively addressing the complaints that waste everyone's time.

And here's the secret sauce: Syntax Snob is actually useful. By automating the trivial stuff, it forces reviewers to engage with what actually matters—the logic, the architecture, the security implications. It's like giving your team a collective ADHD medication that helps them focus on substance over style.

How to Use It: Passive-Aggressive Peace in 5 Minutes

Getting started with Syntax Snob is easier than explaining to your team why you're still using var instead of let. First, install it:

npm install syntax-snob --save-dev
# or
yarn add syntax-snob --dev

Then configure it in your package.json or via a .syntaxsnobrc file. The configuration is where the magic happens—you can specify different rule sets for different reviewers, enable the sarcastic commentary, and even set the 'engagement factor' (more on that later).

Here's a snippet from the main configuration logic that shows how it matches styles to reviewers:

function matchReviewerStyle(reviewer, code) {
  const styles = config.reviewerPreferences[reviewer];
  
  if (styles.brackets === 'allman') {
    code = convertToAllman(code);
    addComment(`Converted to ${reviewer}'s preferred Allman style.`);
  }
  
  if (styles.semicolons === 'always') {
    code = addMissingSemicolons(code);
    addComment(`Added semicolons because ${reviewer} believes in punctuation.`);
  }
  
  return code;
}

Check out the full source code on GitHub to see all the beautifully petty details.

Key Features: The Art of Automated Pettiness

• Pre-commit hook that auto-fixes trivial style 'violations' to the reviewer's personal preference: No more manual reformatting. Syntax Snob learns what each reviewer cares about (or what they complain about most) and pre-emptively addresses it. It's like having a psychic assistant who knows exactly which hills your colleagues are willing to die on.
• Generates a dramatic, sarcastic diff comment for each 'fixed' item: Every automated change comes with commentary that ranges from mildly amused to devastatingly sarcastic. Examples include: "Converted tabs to spaces because we're not animals," "Alphabetized imports because chaos is for other teams," and "Added JSDoc comment that says nothing but looks professional."
• Optionally adds a configurable percentage of intentional, new style 'errors' to keep the reviewer engaged: This is the feature for teams who can't quit the drama. Set it to 5%, and Syntax Snob will intentionally introduce minor style violations—a missing semicolon here, an extra space there—to give reviewers something to find. It's like leaving out Easter eggs for people who enjoy being outraged.

The Beautiful Irony: It Actually Works

Here's the unexpected truth: teams that use Syntax Snob report that their code reviews become more substantive within weeks. When the trivial formatting debates are automated away (with hilarious commentary), reviewers actually start reading the code instead of just scanning for style violations. Security issues get caught earlier. Architectural problems get discussed. The emotional temperature of reviews drops from 'boiling' to 'mildly warm.'

Some teams have even reported using the sarcastic comments as a team bonding mechanism—the over-the-top commentary becomes an inside joke that highlights the absurdity of the whole enterprise. When you're laughing about "removing the existential void represented by this extra newline," it's harder to get genuinely angry about formatting.

Try it out: https://github.com/BoopyCode/syntax-snob. Your team might just discover that the best way to stop arguing about code style is to automate the argument itself—with maximum sarcasm.

After all, if we're going to have holy wars about semicolons, we might as well have them efficiently.