DEV Community: tupe12334

Why You Should Start Using Negative If Statements in Your Code

tupe12334 — Tue, 24 Mar 2026 13:04:06 +0000

We've all been there: the code looks fine, the tests pass, but somehow bugs still make it to production. So what can you do to write more correct code and significantly reduce the number of bugs?

One technique I use regularly to prevent exactly these situations is writing negative if statements — also known as the Early Return pattern.

What Does That Actually Mean?

Instead of first checking the case where the action should happen, you check the invalid cases first and eliminate them as early as possible. This approach makes your code significantly more readable and focused.

For example, instead of writing this:

if (user.isLoggedIn && user.hasPermission) {
  performSensitiveAction();
}

It's better to use a negative check:

if (!user.isLoggedIn || !user.hasPermission) {
  // Handle the invalid situation
  // Make sure to log it
  // throw | return | continue
}

performSensitiveAction();

The happy path — the thing you actually want to do — sits at the bottom, unindented and obvious. Each guard at the top handles one specific failure case.

Why Is This Better?

Readability: The code becomes clearer and more focused because edge cases are checked and dismissed upfront. You don't have to mentally track nested conditions to understand what the function actually does.
Safety: It's easier to spot bugs and prevent them from escaping, because critical conditions are checked explicitly and visibly at the top.
Maintainability: It's much easier to add new conditions or handle additional cases when your checks are clearly laid out at the start of the function.

Log the Failure While You're There

When you use negative if statements, you get a natural place to document why an action didn't succeed. This is the perfect spot to add detailed logs that help you debug the system both in real time and after the fact.

Here's a more complete example:

if (!user.isLoggedIn) {
  logger.warn(`Access attempt without login: ${request.ip}`, {
    userId: user.id,
  });
  return res.status(401).send("Please login first");
}

if (!user.hasPermission) {
  logger.warn(`Permission denied for user: ${user.id}`, {
    action: "performSensitiveAction",
    requiredPermission: "admin",
  });
  return res.status(403).send("Insufficient permissions");
}

performSensitiveAction();

Good logging at these guard points enables:

Security tracking — detecting unauthorized access attempts
Bug understanding — logs show exactly what happened when something went wrong
Better UX — you can identify where users get stuck
Faster response times — support teams can resolve issues faster with full context

Pair It with Proper Error Handling

Logging is part of the picture, but error handling matters too:

Use try/catch — especially for async operations or calls to external resources
Return clear error messages — so users know what happened and what to do
Monitor automatically — tools like Sentry or LogRocket track errors in real time so nothing slips by silently

Combining negative if statements with solid error handling makes your code not just more readable, but more resilient and reliable.

The Counter-Argument

Sometimes, writing too many early returns makes a long or complex function harder to follow. When a function spans many lines and has a dozen early exits, it can become difficult to track the overall flow.

So Which Is Better?

Like most things in code: balance matters.

For short, focused functions, negative if statements are almost always a win. For long, complex functions, it's sometimes better to keep a positive if structure — and invest instead in breaking the function into smaller pieces.

Since I started using this pattern consistently, the number of bugs reaching production dropped significantly, and code reviews became much smoother.

For a deeper dive into this idea, I highly recommend this video by CodeAesthetic:

Do you use early returns consistently? Are there cases where you intentionally avoid them? I'd love to hear your take in the comments.

Why I Built an ESLint Rule That Forces className on Every HTML Element

tupe12334 — Wed, 18 Feb 2026 12:06:54 +0000

You paste a React component into an LLM and ask it to "change the padding on the header div." The LLM responds — but it modified the wrong <div>. You try again: "no, the second div, the one wrapping the title." Two more rounds of back and forth until it finally understands which element you meant.

I got tired of this. So I built eslint-plugin-jsx-classname — an ESLint plugin that enforces className on every HTML element in your JSX. Not for styling. For giving every element a name that both humans and LLMs can reference unambiguously.

The Problem: Anonymous Elements

In most React codebases, it's easy for bare HTML elements to slip through code review:

function Card({ title, children }) {
  return (
    <div>
      <div>
        <span>{title}</span>
      </div>
      <div>{children}</div>
    </div>
  );
}

Now tell an LLM to "add margin to the content wrapper." Which <div> is the content wrapper? The LLM has to guess based on structure, and it often guesses wrong. You end up spending more time correcting the AI than writing the code yourself.

Compare that to:

function Card({ title, children }) {
  return (
    <div className="card">
      <div className="card-header">
        <span className="card-title">{title}</span>
      </div>
      <div className="card-body">{children}</div>
    </div>
  );
}

Now "add margin to card-body" is unambiguous. The LLM knows exactly which element you mean. No back and forth. No guessing. One prompt, one correct edit.

Why This Matters Now

AI-assisted coding is becoming the norm. Whether you're using Claude, Copilot, or Cursor — you're constantly describing parts of your UI to an LLM. Semantic class names act as a shared vocabulary between you and the AI.

Without them, every conversation about your JSX becomes a game of "which div do I mean?" With them, you can point at any element by name. It's the difference between giving directions with street names versus "turn left at the third building after the tall one."

What the Plugin Does

eslint-plugin-jsx-classname provides a single rule: require-classname. It checks every HTML element in your JSX and reports when className is missing.

⚠ HTML element <div> is missing a className attribute.

It only checks standard HTML elements — custom components like <MyButton> or <Card> are ignored, since they already have a name.

Installation

npm install --save-dev eslint-plugin-jsx-classname

Configuration

The plugin uses ESLint flat config. The quickest way to get started:

// eslint.config.js
import jsxClassname from "eslint-plugin-jsx-classname";

export default [jsxClassname.configs.recommended];

This enables the rule as a warning with default options. For stricter enforcement:

export default [jsxClassname.configs.strict];

The strict config sets the rule to error level and enables ignoreTailwind (more on that below).

Customizing the Rule

Check Only Specific Elements

If enforcing className on every element is too aggressive for your codebase, narrow it down:

rules: {
  "jsx-classname/require-classname": ["warn", {
    elements: ["div", "span", "section"]
  }]
}

Exclude Certain Elements

Some elements don't need names — <hr>, <br>, or <input type="hidden">:

rules: {
  "jsx-classname/require-classname": ["warn", {
    excludeElements: ["hr", "br", "input"]
  }]
}

The Tailwind Trap

This is the option I'm most excited about. If your team uses Tailwind CSS, you've probably seen this:

<div className="flex items-center justify-between p-4 mt-2">
  <span className="text-lg font-bold text-gray-800">{title}</span>
</div>

Technically, every element has a className. But these are all Tailwind utilities — the element still has no semantic identity. Tell an LLM "modify the flex items-center justify-between p-4 mt-2 div" and you're back to the same problem.

With ignoreTailwind: true, the rule requires at least one non-Tailwind class:

rules: {
  "jsx-classname/require-classname": ["error", {
    ignoreTailwind: true
  }]
}

Now this fails:

<div className="flex items-center p-4" />

But this passes:

<div className="card-header flex items-center p-4" />

You get Tailwind utilities for styling, plus a semantic class name that gives the element a referenceable identity.

Under the hood, Tailwind detection uses tailwind-merge to programmatically identify utility classes. This means it stays current with Tailwind updates automatically, without maintaining a massive regex list.

"But That's a Lot of Work"

That's the first thing people say. Adding a meaningful className to every single HTML element? In the past, that would have been tedious busywork that no team would actually maintain.

But here's the thing — we're not writing all the code ourselves anymore. Your AI coding agent is already generating most of the JSX. With this lint rule in place, the agent simply adds semantic class names as it writes components. It's zero extra effort for you.

And to make sure the agent never skips the pre-commit hooks that enforce this rule, pair it with block-no-verify. This package prevents --no-verify from bypassing git hooks, so the lint rule is always enforced — no matter who or what is committing the code.

The combination is simple: the lint rule defines the standard, the agent does the work, and block-no-verify makes sure nothing slips through.

Give It a Try

npm install --save-dev eslint-plugin-jsx-classname

Check out the full documentation and source on GitHub. If it's useful to you, a star would mean a lot.

How do you handle communicating with LLMs about your UI components? I'd love to hear your approach in the comments.

The Project Cookbook

tupe12334 — Sun, 08 Feb 2026 14:31:12 +0000

After a year in a new workplace I have noticed several development lifecycle tools that are missing from projects all over, some have it partially, some not at all.

This article covers the essential tools that will improve your team's development experience and code maintainability.

pnpm

We all know npm, this is the go-to, youtube tutorial, default package manager in the NodeJS ecosystem.
In every code boot-camp or school you will learn npm, as a derivative of that fact and the fact that the npmjs.com registry is the default registry for NodeJS packages we come to the result that the npm package manager is the most used package manager in the NodeJS ecosystem.
But is it the best?
It's a matter of opinion, but no, it's not.
There are several package managers in the NodeJS ecosystem, the most popular ones are yarn and pnpm.
Both of them are great, but I prefer pnpm for several reasons:

Performance: pnpm is faster than npm and yarn in most cases, this is because pnpm uses a unique approach to store packages, it creates a single store for all packages and uses hard links to link the packages to the project, this way it avoids duplication of packages and saves disk space.
Determinism: pnpm is more deterministic than npm and yarn, this means that the same set of dependencies will always result in the same set of installed packages, this is important for reproducible builds and for avoiding issues with dependency resolution.
Monorepo support: pnpm has built-in support for monorepos, this means that you can manage multiple packages in a single repository with ease, this is important for large projects and for teams that work on multiple packages.
Strictness: pnpm is more strict than npm and yarn, this means that it enforces stricter rules for dependency resolution and package installation, this helps to avoid issues with conflicting dependencies and ensures that the project is always in a good state.

For these reasons, I recommend using pnpm as the package manager for your NodeJS projects.
But again, it's a matter of opinion, you should try both and see which one works best for you and your team.

ESLint

ESLint is likely the most adopted tool on this list, so I'll keep this brief—if you're reading an article about project tooling, you probably already know what it does.

What's worth mentioning: ESLint 9 introduced flat config (eslint.config.js), which simplifies configuration significantly. If you're still using .eslintrc, consider migrating. The official documentation covers the migration path.

Prettier

Prettier eliminates formatting debates—tabs vs spaces, semicolons, quote style—by enforcing a consistent style automatically.

Configure it with a .prettierrc file and integrate it with ESLint using eslint-config-prettier to avoid rule conflicts.

cspell

Typos are the enemy of code quality—they make code harder to read and search for.

cspell is a spell checker designed for code. Unlike regular spell checkers, it understands camelCase, PascalCase, and snake_case, so it won't flag getUserById as a typo.

Configure it with a cspell.json file:

{
  "version": "0.2",
  "language": "en",
  "words": ["myproject", "signup", "authtoken"],
  "ignorePaths": ["node_modules", "dist", "coverage", "pnpm-lock.yaml"]
}

Add project-specific terms to the words array. VS Code users can install the Code Spell Checker extension for real-time feedback.

knip

Dead code is a silent burden—it increases bundle size, confuses developers, and makes refactoring harder.

knip finds unused files, dependencies, and exports across your entire project—not just unused variables within a file. It detects:

Unused files not imported anywhere
Unused dependencies in package.json
Unused exports never imported elsewhere
Unlisted dependencies used but not declared

Configure it with a knip.json file:

{
  "entry": ["src/index.ts", "src/main.ts"],
  "project": ["src/**/*.ts"],
  "ignore": ["**/*.test.ts", "**/*.spec.ts"],
  "ignoreDependencies": ["@types/*"]
}

Running knip regularly keeps your codebase lean and makes refactoring easier.

Husky

Now that we have all these quality tools, we need a way to enforce them on every commit and push. Git hooks can do this, but they're local to your machine—not shareable with the team.

Husky solves this by placing hook scripts in a .husky folder that gets committed to the repository and automatically installed when running pnpm install.

A typical pre-commit hook runs lint-staged (covered next), while a pre-push hook ensures you don't push broken code:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
pnpm tsc --noEmit && pnpm test --run

This runs type-checking and tests before every push. If either fails, the push is blocked.

lint-staged

But wait—what if you have work-in-progress code in your working directory that isn't ready for linting? You don't want unfinished code blocking your commit.

lint-staged runs validation tools only on staged files, so you can commit clean code while keeping your messy experiments untouched.

Configure it in .lintstagedrc.json:

{
  "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"],
  "*.{json,md}": ["prettier --write"],
  "*.{ts,tsx,js,md,json}": ["cspell lint --no-must-find-files"]
}

Commitlint With Conventional Commits

We all saw that commit message that was "fix" or "update" or even "fox" or the worse: ".".

We all wondered what was fixed or updated, and we all wished that the commit message was more descriptive.

This is the job of commitlint, to make sure your co-workers (and you) write good commit messages.

Commitlint is a tool that helps us to enforce a consistent commit message format, this is important for several reasons, it makes it easier to understand the history of the project, it makes it easier to generate changelogs, and it makes it easier to automate the release process.
We can use commitlint with the conventional commits format to enforce a consistent commit message format.
The conventional commits format is a specification for adding human and machine readable meaning to commit messages, it consists of a type, a scope, and a subject, for example:

feat(auth): add login functionality
fix(api): fix the bug in the user endpoint
docs: update the README file

We can configure commitlint to use the conventional commits format by installing the @commitlint/config-conventional package and creating a commitlint.config.js file like this:

module.exports = { extends: ["@commitlint/config-conventional"] };

Dependabot/Renovate

Keeping dependencies up to date is crucial for security and stability, but manually checking for updates is tedious and often forgotten.
This is where automated dependency update tools come in.

Dependabot is GitHub's built-in solution for automated dependency updates.
It scans your package.json (and other dependency files) and opens pull requests when new versions are available.

Renovate is a more powerful and flexible alternative that works across multiple platforms (GitHub, GitLab, Bitbucket, etc.).
It offers features like grouping updates, automerging minor updates, and custom scheduling.

Both tools integrate with your CI pipeline, so you can ensure that updates don't break your tests before merging.

Which one should you use? Dependabot is simpler and requires no setup if you're on GitHub.
Renovate offers more control and works across platforms, making it ideal for complex projects or organizations with specific update policies.

Centy

Issue tracking is essential for any project, but traditional tools like Jira or Linear live outside your codebase, creating a disconnect between your code and your tasks.

Centy takes a different approach by storing issues as Markdown files directly in your repository.
This means your issues live alongside your code, are version controlled with git, and require no external services or databases.

Why is this approach beneficial?

Git-friendly: Issues are plain Markdown files, so you can track changes, review history, and collaborate using the same git workflow you use for code.
Offline-first: Everything runs locally, no internet connection or external service required.
AI-ready: Designed to work seamlessly with AI coding assistants, making it easy to reference and resolve issues programmatically.
Simple: No complex setup, no accounts, no subscriptions. Just initialize and start tracking.

If you prefer keeping everything in one place and want your issue tracking to be as version-controlled as your code, Centy is worth exploring.

Summary

These tools form a quality pipeline that catches issues at every stage:

pnpm manages dependencies efficiently
ESLint + Prettier keep your code consistent and clean
cspell catches typos before they become permanent
knip removes dead weight from your codebase
Husky + lint-staged enforce quality on every commit
Commitlint keeps your git history readable
Dependabot/Renovate keep dependencies fresh
Centy tracks issues alongside your code

You don't need to adopt everything at once. Start with ESLint, Prettier, and Husky—they give you the most impact for the least effort. Add the others as your project matures.

The goal isn't to have the most tools, it's to have the right tools that help your team ship better code with less friction.

Full disclosure: I am the creator of Centy, AI assisted fixing typos in this article.

How I Stopped My AI Coding Assistant from Cheating on Git Hooks

tupe12334 — Tue, 13 Jan 2026 16:12:00 +0000

TL;DR: I built block-no-verify - a tool that prevents AI agents like Claude Code from using --no-verify to bypass git hooks. The AI must fix issues properly; humans keep full autonomy.

The Problem I Didn't Know I Had

I've been using Claude Code as my AI pair programmer. It's genuinely impressive - writes code, runs tests, commits changes. But one day I noticed something odd in my git history.

My pre-commit hooks weren't catching issues they should have caught.

I dug into what was happening and found the culprit:

git commit -m "fix: update validation logic" --no-verify

Claude Code was using --no-verify on almost every commit. Silently bypassing all my carefully configured hooks.

Why This Matters

Git hooks exist for a reason. Mine run:

ESLint - catch code quality issues
Prettier - enforce consistent formatting
Type checking - prevent TypeScript errors from slipping through
Commit message validation - keep a clean, conventional commit history

When the AI bypasses these, I'm essentially getting unreviewed code merged into my codebase. The very guardrails I set up to maintain quality were being circumvented.

I get why Claude Code does this - hooks can fail, hooks can be slow, and the AI is trying to be efficient. But efficiency at the cost of quality isn't a trade-off I want to make.

The Solution: Enforce the Rules

Instead of hoping for a configuration option that might never come, I built a tool that intercepts git commands before they execute.

Meet block-no-verify.

How It Works

Claude Code has a hooks system that lets you run scripts before certain actions. I use the PreToolUse hook to inspect every Bash command before it runs:

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm dlx block-no-verify"
          }
        ]
      }
    ]
  }
}

When Claude Code tries to run something like:

git commit -m "feat: add new feature" --no-verify

The tool detects the forbidden flag and blocks the command with a clear message:

❌ Blocked: --no-verify flag is not allowed
The --no-verify flag bypasses git hooks which enforce code quality.
Please fix any issues that would cause hooks to fail.

Smart Detection

One tricky part: the -n shorthand means different things for different git commands:

Command	`-n` means	Blocked?
`git commit -n`	`--no-verify`	Yes
`git push -n`	`--dry-run`	No
`git merge -n`	`--no-commit`	No

The tool understands this context and only blocks when -n actually means "skip verification."

It also handles edge cases like:

Flags embedded in strings: git commit -m "--no-verify is blocked" (allowed - it's just a message)
Shell syntax: echo "--no-verify" | git commit (detected)
Command chaining: git add . && git commit --no-verify (blocked)

The Philosophy: Asymmetric Governance

Here's what I didn't want: a tool that blocks --no-verify for everyone.

Sometimes I need to bypass hooks. Maybe I'm doing a large refactor and want to commit work-in-progress. Maybe there's a false positive in my linter. As the developer, I can make that judgment call.

But the AI shouldn't make that call for me.

So block-no-verify only affects commands run through Claude Code's hook system. When I run git commands directly in my terminal, nothing changes. Full autonomy preserved.

AI agent → Must follow the rules, fix issues properly
Human developer → Can override when they judge it appropriate

This is what I call asymmetric governance. The AI operates under stricter constraints than the human, because the human understands context that the AI doesn't.

The Results

Since implementing this, Claude Code actually fixes the issues instead of bypassing them.

Hook fails because of a lint error? The agent reads the error, fixes the code, and commits cleanly.

This creates a positive feedback loop:

Hook fails
Agent investigates the failure
Agent fixes the root cause
Code quality actually improves

Compare this to the bypass behavior:

Hook would fail
Agent uses --no-verify
Problem hidden
Technical debt accumulates silently

Getting Started

Installation

Add to your Claude Code settings:

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm dlx block-no-verify"
          }
        ]
      }
    ]
  }
}

That's it. No global installation, no configuration. The tool reads the command from stdin (passed by Claude Code) and exits with an error if --no-verify is detected.

Broader Implications

As AI coding assistants become more capable and autonomous, we need to think about governance. These tools are powerful, but they optimize for completing tasks - not necessarily for maintaining the standards we've set up.

Git hooks, linters, tests - these are encoded team knowledge. They represent decisions we've made about quality. When an AI bypasses them, it's not just skipping a step; it's ignoring institutional wisdom.

block-no-verify is a small tool solving a specific problem, but it represents a larger pattern: programmatic enforcement of AI behavior. Rather than relying on prompts or hoping the AI "does the right thing," we can build guardrails that make certain behaviors impossible.

What's Next?

I'm considering extending this pattern to other "escape hatch" behaviors:

git push --force to protected branches
git reset --hard without confirmation
Other flags that could cause irreversible damage

I've also been working on eslint-config-agent - an ESLint configuration specifically designed for codebases where AI agents are writing code. The idea is to have stricter, more opinionated linting rules that catch the kinds of mistakes AI tends to make. Combined with block-no-verify, it creates a solid quality gate that AI-generated code must pass through.

If you're using AI coding assistants and care about maintaining your code quality standards, give block-no-verify a try. I'd love to hear your feedback on both projects - what rules would you add to eslint-config-agent? What other guardrails have you found useful when working with AI assistants?

Links:

Have you run into similar issues with AI coding assistants bypassing your safeguards? What other governance patterns have you found useful? Let me know in the comments.

Compilation vs. Transpilation

tupe12334 — Wed, 21 Dec 2022 16:23:42 +0000

TLDR

Compilation is the process of turning source code into machine code, while transpilation is the process of turning source code from one high-level language into another.

Background story

Today I had a conversation with two of my colleagues about the difference between compilation and transpilation. They asked me to explain it to them in simple terms, and I thought it would be a great idea to write an article about it for anyone who might be wondering about the same thing.

Compilation and transpilation are both processes that involve turning source code written in one programming language into another. However, there are some key differences between the two that I will explain below.

Compilation

Compilation is the process of converting source code written in a high-level programming language (such as C++ or Java) into machine code that can be run on a computer. This machine code is specific to the type of processor that the computer is using and is generally not readable by humans. Compiling source code allows it to be run more efficiently on a computer, as the machine code is optimized for the specific processor it is being run on.

Transpilation

Transpilation, on the other hand, involves converting source code from one high-level programming language into another. For example, transpiling TypeScript to JavaScript involves taking source code written in TypeScript and converting it into JavaScript. This process is often used to allow code written in newer or less widely-used programming languages to be used in environments where those languages are not supported.

Typescript and JavaScript

One example of transpilation in action is the conversion of TypeScript code to JavaScript. TypeScript is a programming language that was developed by Microsoft and is a superset of JavaScript. It adds features to JavaScript such as static typing and class-based object-oriented programming, which can make it easier to write large-scale applications. However, not all environments support TypeScript, so transpiling it to JavaScript allows it to be used in those environments.

Feel free to contact me

I hope this explanation of the difference between compilation and transpilation has been helpful! If you have any questions or would like further information, please don't hesitate to ask.

Full Disclosure

I used tools such as ChatGPT and Grammarly to help me write this article. These tools assisted in the writing process by suggesting alternative phrases and correcting grammar errors, but the content of the article is entirely my own work.