DEV Community: Aniket Bhattacharyea

The Best AI Code Review Tools of 2026

Aniket Bhattacharyea — Fri, 20 Feb 2026 13:25:32 +0000

Early AI code review tools had a math problem. For every real bug they caught, they flagged nine false positives. Teams got buried in comments about variable naming conventions and whitespace. They started ignoring the bot entirely. Productivity tanked.

The tools that made it past 2025 didn't just throw better models at the problem. They rebuilt how code review works from scratch.

This guide covers the AI code review tools worth using in 2026, what they're actually good at, and which specific problems they solve for your team.

The Core Problem: Context Windows vs. Large Diffs

AI reviewers break down when you feed them too much code at once. A 1,000-line diff overwhelms the context window. The model loses coherence, misses connections between changes, and falls back on pattern matching for style issues.

The same reviewer that produces noise on large diffs produces useful feedback on small ones. The tool didn't get smarter. You gave it a problem it could actually solve.

This is why the effective tools in 2026 either enforce small changes (Graphite), sacrifice depth for speed (GitHub Copilot), or index your entire codebase upfront (Greptile).

Tool Comparison Matrix

Tool	Best For	Platform Support	Analysis Depth	False Positive Rate	Price/User/Mo
Graphite Agent	Teams adopting stacked PRs	GitHub only	Deep (full codebase)	~3% unhelpful	\$40
GitHub Copilot	Existing Copilot users	GitHub only	Surface (diff-based)	Medium	\$10-39 (bundled)
CodeRabbit	Multi-platform teams	GitHub, GitLab, Bitbucket, Azure	Surface (diff-based)	Medium	\$24-30
Greptile	Maximum bug detection	GitHub, GitLab	Deep (full codebase)	Highest	\$30
BugBot	Cursor-native teams	GitHub only	Medium (8-pass diff)	Low-Medium	\$40 + Cursor

Graphite Agent

Graphite Agent combines full-codebase understanding with stacked PRs. Instead of one massive pull request, you break changes into small, dependent PRs that merge in sequence.

Here's how stacked PRs work:

Shopify reported 33% more PRs merged per developer after adoption, with 75% of PRs now going through Graphite. Asana saw engineers save 7 hours weekly, ship 21% more code, and cut median PR size by 11%.

Agent maintains an unhelpful comment rate under 3%. When it flags an issue, developers change the code 55% of the time. Human reviewers hit 49%.

The tool provides one-click fixes, resolves CI failures inline, and includes a merge queue that coordinates landing changes in order.

The constraint: GitHub-only, and your entire team needs to adopt stacked workflows. For teams that commit to this change, median PR merge time drops from 24 hours to 90 minutes.

Pricing: Team plan at \$40/user/month with unlimited reviews. Free tier for individuals. Enterprise pricing on request.

GitHub Copilot Code Review

GitHub Copilot Code Review hit general availability in April 2025 and reached 1 million users in a month. You assign Copilot as a reviewer like any teammate. It leaves inline comments with suggested fixes.

The October 2025 update added context gathering. Copilot now reads source files, explores directory structure, and integrates CodeQL and ESLint for security scanning.

What it's good at: Zero friction if you already pay for Copilot. Catches typos, null checks, and simple logic errors.

What it misses: Architectural problems and cross-file dependencies. It's diff-based, so it only sees what changed in the PR.

Pricing: Bundled with Copilot subscriptions (\$10-39/month depending on tier). Code review features not available on free tier.

CodeRabbit

CodeRabbit is the most widely installed AI code review app on GitHub and GitLab. Over 2 million repositories connected, 13 million+ PRs processed. It runs automatically on new PRs, leaving line-by-line comments with severity rankings and one-click fixes.

The advantage: Platform breadth. Supports GitHub, GitLab, Bitbucket, and Azure DevOps. Integrates 40+ linters and SAST scanners. Offers self-hosted deployment for enterprises with 500+ seats.

The limitation: Diff-based analysis. It sees what changed in the PR, not how changes interact with your codebase. Independent benchmarks gave it a 1/5 completeness score for catching systemic issues.

Pricing: Pro plan at \$24-30/user/month. Free tier with basic PR summaries. Enterprise plans with self-hosting available.

Greptile

Greptile indexes your entire repository and builds a code graph. It uses multi-hop investigation to trace dependencies, check git history, and follow leads across files.

Version 3 (late 2025) uses the Anthropic Claude Agent SDK for autonomous investigation. The tool shows you evidence from your codebase for every flagged issue.

At \$30/developer/month with a \$180M valuation after its Benchmark-led Series A, Greptile offers the deepest context-aware analysis available.

The tradeoff: Highest catch rate, but also highest false positive rate in independent evaluations. You get more real bugs and more noise.

Pricing: \$30/developer/month for unlimited reviews. Discounts for annual commitments. Open-source projects may qualify for free usage. Self-hosted and enterprise pricing on request.

BugBot

BugBot from Cursor launched in July 2025 and reviews 2 million+ PRs monthly. It runs 8 parallel review passes with randomized diff order on every PR, catching bugs that single-pass reviewers miss.

The "Fix in Cursor" button jumps you from review comment to editor with the fix pre-loaded. Discord's engineering team reported BugBot finding real bugs on human-approved PRs. Over 70% of flagged issues get resolved before merge.

The constraint: Tightly coupled to Cursor. You need a Cursor subscription, and it works best when your team already uses Cursor as their primary editor.

Pricing: \$40/user/month plus Cursor subscription. 14-day free trial. GitHub-only.

Why Smaller PRs Get Better Results

Research shows 30-40% cycle time improvements for PRs under 500 lines, with diminishing returns above that threshold. Teams using stacked PRs ship 20% more code with 8% smaller median PR size, saving roughly 10 hours per week waiting to merge.

The same AI reviewer produces signal on a 150-line diff and noise on a 1,000-line one. The tool didn't change. The workflow gave it a solvable problem.

Decision Framework

Pick based on what you're willing to change:

No workflow changes: Start with GitHub Copilot if you already pay for it. Zero setup, catches obvious bugs.

Multi-platform support: CodeRabbit is the only option that works across GitHub, GitLab, Bitbucket, and Azure DevOps.

Maximum bug detection: Greptile's full-codebase indexing finds issues other tools miss. Accept higher noise as the tradeoff.

Cursor workflow: If your team lives in Cursor, BugBot extends your existing setup.

Workflow transformation: Graphite treats code review as a systems problem. The numbers from Shopify (33% more PRs per developer) and Asana (7 hours saved weekly) came from adopting stacked workflows, not just adding AI.

Integration and Security

AI code review tools plug directly into GitHub, GitLab, and Bitbucket as automated reviewers. They integrate with CI/CD pipelines, offer IDE plugins for real-time feedback, and support webhook triggers for automatic reviews on code push.

Security varies by provider. Look for encryption in transit and at rest, SOC 2 compliance, and clear data retention policies. Some tools offer self-hosted options for maximum control. Graphite has a privacy-first approach that guarantees code stays private and isn't used for model training.

Cost ranges from \$10-50 per user monthly for standard plans. GitHub Copilot Code Review bundles with existing subscriptions (\$10-39/month). Enterprise plans with custom rules and dedicated support cost more. Self-hosted options may use infrastructure-based pricing instead of per-user costs.

What Actually Matters

The AI code review tools that survived 2025 didn't just add smarter models. They rethought workflows. Graphite built a platform around stacked changes. GitHub Copilot traded depth for zero friction. CodeRabbit went for breadth across platforms. Greptile went all-in on context. BugBot integrated tightly with an editor.

The right tool depends on what you're willing to change. If you want AI review with no disruption, GitHub Copilot works. If you need multi-platform support, CodeRabbit is your only option. If catching deep bugs matters more than noise, Greptile's full-codebase indexing finds things others miss. If your team lives in Cursor, BugBot fits naturally.

If you're willing to change how your team works, not just add a bot, Graphite treats code review as a workflow problem. Stacked PRs, AI review, and merge queue work together in ways that separate tools can't replicate. The productivity gains came from the workflow change, not just the AI.

Stacking up Graphite in the World of Code Review Tools

Aniket Bhattacharyea — Fri, 23 Jan 2026 13:07:13 +0000

A developer's guide to navigating the crowded market of AI code review assistants in 2026.

The "Review Bot" Explosion

2025 is the year every engineering team tried to automate code review. If you opened a pull request this year, chances are an AI left a comment on it. Some of those comments caught real bugs. Many did not.

The problem isn't that AI code review doesn't work. It's that the market is flooded with tools that look similar on the surface but solve fundamentally different problems. One tool might catch off-by-one errors in your IDE before you even push. Another scans your entire repository history to understand cross-file dependencies. A third lives in your GitHub comments, leaving feedback that ranges from brilliant to pedantic.

For the average developer or tech lead, it's hard to tell the difference between a wrapper around an LLM and an actual platform. This article cuts through that noise.

I'll compare five tools—Graphite, GitHub's native review, CodeRabbit, Greptile, and BugBot—using three criteria:

Depth: Does it understand your whole codebase, or just the diff?
Workflow: Does it change how you review, or just what you read?
Noise: Does it help you ship faster, or spam your PR timeline?

Let's start by categorizing these tools by what they actually do.

Category 1: The "Workflow Platform"

Tool: Graphite Agent

Graphite is an AI-augmented code review and pull request workflow platform designed to help teams ship higher-quality code faster by rethinking how reviews and merges work. It integrates AI feedback directly into pull requests, supports stacked pull request workflows, and provides automated merge orchestration.

When you open a pull request with Graphite, the Graphite Agent provides AI-driven feedback directly in the PR page. It focuses on delivering high-signal insights rather than large volumes of superficial comments. The platform is built to help teams catch substantive bugs and issues early in the review cycle.

A key workflow innovation is stacked pull requests. With the Graphite CLI and tooling, developers can create a series of dependent PRs—each building on the last—so you can continue working on PR #3 while PR #1 and #2 are still under review. When an earlier PR merges, subsequent stacked changes are automatically rebased, helping reduce merge conflicts and keeping development unblocked.

Graphite also includes a stack-aware merge queue. Instead of merging PRs sequentially and running CI for each one in isolation, the merge queue can batch and test multiple PRs in parallel once they’re ready, speeding up the merge process and reducing wait times.

In addition to AI review and stacking workflows, Graphite offers a modern PR review interface with unified inboxes, GitHub integrations, a CLI, and editor extensions (e.g., VS Code). These features aim to streamline the development and review experience and reduce context switching.

Best for: Teams that find traditional GitHub review workflows slow or fragmented, and that would benefit from structured, smaller changesets, automated rebasing, and integrated AI feedback throughout the pull request lifecycle.

Pricing:

Free (Hobby): Essentials, including CLI for stacked PRs, VS Code extension, and limited access to Graphite Agent and AI reviews.
Starter: $20/user/month (billed annually), includes support for all GitHub organization repos and team insights.
Team: $40/user/month (billed annually), adds unlimited Graphite Agent access, unlimited AI reviews, review customizations, automations, and merge queue.
Enterprise: Custom pricing with advanced controls, security features, and support.

Category 2: The "Native Giant"

Tool: GitHub

GitHub’s native code review workflow is the baseline most teams start from. It is reliable, familiar, and requires no additional tooling beyond what teams are already using for source control and pull requests.

GitHub has added AI-assisted review features through Copilot (including Copilot for Business and Copilot Enterprise). These capabilities can summarize pull requests, explain changes, and suggest improvements directly in comments. In practice, the quality of these suggestions varies: some feedback is genuinely helpful, while other comments are generic or low value. Importantly, Copilot acts as an assistive layer rather than a fully autonomous review agent.

A core limitation is architectural. GitHub’s pull request model is fundamentally linear: one branch, one PR, one review lifecycle. There is no native support for stacked or dependent pull requests, which makes it harder to work on large changes incrementally without introducing workflow friction.

For static analysis and security scanning, GitHub offers CodeQL. Public repositories get CodeQL scanning by default. For private repositories, full CodeQL integration—security alerts, dashboards, and UI support—requires GitHub Advanced Security, which introduces additional cost and setup. CodeQL analysis is deep and reliable, but it prioritizes correctness over speed and is not optimized for fast, conversational PR feedback like AI-first reviewers.

Best for: Teams that value stability and minimal workflow disruption, and that prefer to stay within the existing GitHub ecosystem. If adopting new tools or changing review workflows is a hard sell, GitHub’s native features are often “good enough” for baseline review automation.

Notable limitation: Merge queue availability is restricted to higher-tier GitHub plans and is not universally accessible. Many teams still merge PRs sequentially and run CI per-PR rather than benefiting from batch testing.

Category 3: The "Comment Bots"

Tool: CodeRabbit

CodeRabbit is a feature-rich AI code reviewer that operates entirely within pull request comments. It combines large language models with a broad set of linters and security scanners to generate comprehensive feedback on code changes. In addition to identifying issues, it can generate PR summaries, create sequence diagrams, suggest fixes, and propose test cases.

The breadth of analysis is both its main strength and its primary trade-off. CodeRabbit surfaces a wide range of findings, but this often includes stylistic feedback and minor suggestions alongside substantive issues. As a result, teams frequently invest time in tuning configuration and rules to reduce noise and focus the output on what matters most for their codebase.

CodeRabbit integrates with major source control platforms, including GitHub, GitLab, Bitbucket, and Azure DevOps. It also provides a VS Code extension that enables pre-PR review, allowing developers to catch issues before opening a pull request. This broad platform support makes it suitable for organizations operating across multiple repositories or hosting providers.

Best for: Open source maintainers or teams that want extensive automated feedback directly in their existing PR workflow, without introducing a new review interface. Its multi-platform support is particularly valuable for organizations that are not GitHub-only.

Pricing: Offers a free tier with basic features such as PR summarization. Paid plans are approximately $24–$30 per user per month (Pro), depending on billing, and unlock advanced analysis and customization options.

Category 4: The "Deep Context" Engine

Tool: Greptile

Greptile takes a fundamentally different approach. Instead of analyzing just the PR diff, it builds a full graph of your codebase—understanding how functions connect, where code is used, and how similar patterns have evolved over time.

This deep context means Greptile can catch issues that span multiple files or reference historical changes. It's like having a reviewer who has memorized your entire repository. The trade-off is complexity: Greptile requires more setup and resources than a simple diff-based tool.

Greptile emphasizes enterprise features: self-hosted deployment, custom AI models, SOC 2 compliance, and support for both GitHub and GitLab. You can run it on-premises if your security team requires it.

Best for: Large codebases where understanding cross-module dependencies is critical. If you're working on a system with millions of lines of code and complex architectural patterns, Greptile's full-repo analysis catches issues that simpler tools miss.

Pricing: ~$30/user/month (cloud), enterprise negotiation for on-prem. 100% off for open-source and 50% off for startups.

Category 5: The "Pre-Merge" Hunter

Tool: BugBot (by Cursor)

Bugbot is a narrowly focused AI code review tool designed to identify logic bugs and security issues with a low false-positive rate. Rather than acting as a full code review or workflow platform, it concentrates on surfacing concrete, actionable problems in code changes.

Bugbot primarily operates on GitHub pull requests. When a PR is opened, it automatically reviews the diff and leaves comments highlighting potential bugs, edge cases, or security concerns. For users of the Cursor IDE, flagged issues can be opened directly in the editor, where suggested fixes can be applied or modified before committing updates.

The tool is optimized for depth over breadth. It intentionally avoids stylistic feedback and general code quality suggestions, focusing instead on issues that are likely to cause incorrect behavior or security risk. Bugbot also supports custom review rules, allowing teams to encode project-specific constraints and conventions.

The primary limitation is scope. Bugbot does not aim to replace a full code review platform: it does not generate PR summaries, manage approvals, or integrate with project management workflows. Its role is confined to automated detection of substantive bugs within pull requests.

Best for: Individual contributors or teams who want automated, high-signal bug detection during PR review—especially those already using Cursor. It can be particularly useful in environments where logic or security defects carry a high operational cost.

Pricing: Bugbot offers a limited free tier for Cursor Teams and Individual plan users. Paid plans are approximately $40 per user per month, depending on usage limits and team features, and are available as add-ons to Cursor plans.

Comparison Matrix

Feature	Graphite	GitHub	CodeRabbit	Greptile	BugBot
Installation	GitHub App + CLI	Native	GitHub App	GitHub App + API	GitHub App
Primary Focus	Workflow + AI	Manual Review	PR Comments	Deep Context	PR Comments
Analysis Scope	PR diff + context	PR diff	PR diff + linters	Full repo graph	Current PR + existing PR comments
Noise Level	Very Low (~5%)	Varies	Medium-High	Low	Very Low
Stacked PRs	✅ Native	❌	❌	❌	❌
Merge Queue	✅	Enterprise only	❌	❌	❌
Pricing	$20-40/user	Included + Copilot	$12-30/user	~$30/user	Limited usage included with Cursor

Which Tool Fits Your Stack?

There's no universal winner. The right choice depends on where your team is blocked.

If your bottleneck is the review process itself—PRs sit too long, developers get blocked, context-switching kills momentum—Graphite's workflow improvements matter more than any AI feature. The stacked PRs and merge queue can cut review time from days to hours, even before the AI comments help.

If you're fully invested in GitHub and Microsoft tools, the native features are adequate. You won't get workflow improvements, but you also won't need to onboard a new platform.

If you need cross-platform support or want comprehensive coverage including linters and security scanners, CodeRabbit delivers. Be prepared to tune its configuration to reduce noise.

If you're working on a massive legacy codebase where understanding historical context is critical, Greptile's full-repo analysis is worth the complexity.

If you're already using Cursor IDE and want to catch bugs before they are merged, BugBot is the most focused solution.

The real question isn't "which AI reviewer is best?" It's "what's actually slowing down my team's shipping velocity?" Answer that first, then pick the tool that addresses it.

What are you running in production? Are you trusting AI to auto-approve yet, or strictly using it for summaries? I'm curious what everyone else is seeing. Drop a comment below.

How to Stack Pull Requests on GitHub (Without Losing Your Mind)

Aniket Bhattacharyea — Fri, 16 Jan 2026 12:25:13 +0000

You just finished building your feature. You open a pull request. Then you wait. And wait. And wait some more.

Meanwhile, the next part of your project is ready to build, but it depends on the code you just submitted. Do you start working anyway and risk a rebasing nightmare? Or do you context switch to something completely different and lose your flow?

This is the "waiting game" that kills productivity. You've probably tried both approaches. Starting the next feature while the first is still under review leads to merge conflicts when changes come back. Context switching to unrelated work destroys your momentum and makes you lose the mental model you built up.

The typical escape hatch is cramming everything into one massive 1,000-line PR. Ship it all at once, avoid branch dependencies entirely. But reviewers hate this. Big PRs take forever to review. Bugs hide in the noise. And if something needs to change, you're back to square one.

There's a better way. Stacked pull requests let you break work into small, reviewable chunks without the Git gymnastics. And the Graphite CLI (gt) makes it stupid simple.

This isn't theory. Companies like Airbnb and Meta have used stacking for years. Now it's available for the rest of us, without building custom tooling.

Why stacking matters

When you stack PRs, you create a chain: PR 1 builds the foundation, PR 2 builds on PR 1, and PR 3 builds on PR 2. Each PR is small and focused. Reviewers can approve them independently. You keep coding without getting blocked.

Think of it like chapters in a book. Each chapter makes sense on its own, but they build toward a larger story. Your reviewer reads chapter 1 (the API), approves it, then moves to chapter 2 (the UI). They're not overwhelmed by 50 pages at once.

The benefits compound:

Faster reviews: A 200-line PR gets reviewed in minutes. A 2,000-line PR sits for days.
Better feedback: Reviewers spot issues when the context is fresh and focused.
Easier debugging: When something breaks, you know exactly which small change caused it.
No blocking: You keep building while waiting for reviews.

The problem? Managing this in vanilla Git is painful. Rebasing changes down the stack, keeping base branches in sync, and avoiding merge conflicts requires constant mental overhead. You spend more time managing branches than writing code.

Graphite automates all of it. The entire workflow becomes three commands: create, submit, restack.

Setup in 60 seconds

Install the Graphite CLI using either Homebrew or npm:

brew installation

brew install withgraphite/tap/graphite
gt --version

npm installation

npm install -g @withgraphite/graphite-cli@stable
gt --version

Sign in to https://app.graphite.com/activate with your GitHub account. You might be prompted to complete the setup if you haven’t done so already. There, you can create a token, and Graphite will provide you with an authentication command to run:

gt auth --token <your_cli_auth_token>

Run this command, which will log you in.

Initialize Graphite in your repo (make sure this repo exists in GitHub, and you chose it for syncing during Graphite setup):

# Creates local config, doesn't modify your actual repo
gt init

That's it. Graphite works alongside Git. You can still use git status, git add, and other standard Git commands. The gt commands just handle the branching logic for you.

Building the first layer: backend API

Let's build a simple todo app. Start with the API endpoints.

Make sure you’re on the main branch:

gt checkout main

Now write your code. Here's a minimal Express API:

// server.js
const express = require('express');
const app = express();

// In-memory storage for todos
let todos = [];

// GET endpoint to fetch all todos
app.get('/api/todos', (req, res) => {
  res.json(todos);
});

// POST endpoint to create a new todo
app.post('/api/todos', express.json(), (req, res) => {
  const todo = { id: Date.now(), text: req.body.text };
  todos.push(todo);
  res.status(201).json(todo);
});

app.listen(3000, () => console.log('Server running on port 3000'));

Now run the following command, which will create a new branch named feat/api and add a commit:

gt create feat/api --all \
      --message "Add API endpoints"

The API is done, but not merged yet. Time to stack the frontend on top.

Stacking the frontend: the magic part

Here's where it gets interesting. The API isn't approved or merged, but you're ready to build the UI:

<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Todo App</title>
</head>
<body>
  <h1>My Todos</h1>
  <input id="todo-input" type="text" placeholder="Add a todo" />
  <button onclick="addTodo()">Add</button>
  <ul id="todo-list"></ul>

  <script>
    // Fetch and display all todos on page load
    async function loadTodos() {
      const response = await fetch('/api/todos');
      const todos = await response.json();
      const list = document.getElementById('todo-list');
      list.innerHTML = todos.map(t => `<li>${t.text}</li>`).join('');
    }

    // Add a new todo via POST request
    async function addTodo() {
      const input = document.getElementById('todo-input');
      await fetch('/api/todos', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ text: input.value })
      });
      input.value = '';
      loadTodos(); // Refresh the list
    }

    loadTodos(); // Initialize on page load
  </script>
</body>
</html>

Run this command, which creates a feat/ui branch:

gt create feat/ui --all \
      --message "Add UI"

Graphite automatically sets feat/api as the parent. You're now working on code that depends on unmerged changes.

You now have two branches, stacked on top of each other, both ready to review. You can check the structure with:

$ gt log short

◉  feat/ui
◯  feat/api
◯  main

Syncing to GitHub: one command

Push everything to GitHub and create PRs:

gt submit --stack

Graphite does three things automatically:

Detects both branches in your stack
Creates two separate PRs on GitHub
Sets the base branch correctly so diffs show only the new changes

On running the command, you’ll be taken to a webpage, where you can add a description for the PRs, and publish them.

On GitHub, the PR for the UI is based on the feat/api branch, not main. This means reviewers see only the UI changes, not the API code.

Handling review feedback: the restack

Your reviewer asks you to rename a variable in the API. In a normal Git workflow, this breaks everything. You'd need to manually rebase the UI branch and pray you don't hit conflicts.

With Graphite, it's automatic.

Check out the API branch:

gt checkout feat/api

Make the change:

// Update variable name in server.js
let todoList = []; // was 'todos'

Commit the changes:

gt modify -a

This will amend the last commit to add the new changes. If you prefer to create a separate commit, you can use this command instead:

gt modify --commit \
    --all \
    --message "Responded to reviewer feedback"

Graphite detects the change and automatically restacks (rebases) feat/ui on top of the updated feat/api code. No conflict resolution needed. No manual rebasing. It just works.

Check your stack again:

gt log short

Both branches are in sync. The UI branch has the latest API changes.

Resubmit the PR:

gt submit --stack --update-only

Pro tips for power users

Visualize your stack. Use gt log short anytime to see where you are:

gt log short

This shows your branch hierarchy at a glance. It's like git log, but focused on your stack structure instead of commit history.

Sync frequently. Start each work session with:

gt sync

This pulls the latest changes from main, detects any merged PRs, and prompts you to delete local branches that are no longer needed. It keeps your stack clean.

You're not locked in. Merge PRs directly on GitHub if you want. Graphite figures it out. You can mix and match workflows. Some team members can use Graphite while others stick with vanilla Git.

Your teammates don't need Graphite. They review PRs on GitHub like normal. Graphite only changes your local workflow, not theirs. The PRs look identical to standard GitHub PRs.

Navigate with commands. Use gt up and gt down to move between branches in your stack:

# Move to the parent branch
gt down

# Move to the child branch  
gt up

This is faster than typing out branch names, especially when you're deep in a stack.

Split changes later. If you realize mid-branch that you should split the work, use gt split:

gt split

Graphite will guide you through splitting commits into separate branches. Useful when you realize a "quick fix" turned into a bigger change.

Amend instead of adding commits. Instead of creating multiple commits on one PR, amend your work:

gt modify -a

This keeps each branch as a single, clean commit. When you need to address review feedback, amend again. The history stays linear and readable.

Why this matters

Stacking lets you code at the speed of thought, not the speed of CI. Small PRs get reviewed faster. Fewer bugs slip through. You stay in flow instead of waiting around.

GitHub's review process is powerful, but it wasn't built for this workflow. Graphite fills the gap. It's like adding power steering to your development process.

Resources

Have you tried stacking before? Drop a comment and let me know if you prefer big PRs or small stacks.

The 6 Best AI Code Review Tools for Pull Requests in 2025

Aniket Bhattacharyea — Fri, 12 Dec 2025 16:11:53 +0000

A comprehensive comparison of platforms, bots, and agents to speed up your code review cycle.

Introduction: The "Review Gap" in the Age of AI

AI code generation tools like GitHub Copilot and Cursor have fundamentally changed how developers write code. What once took hours now takes minutes. A single developer can output 2-3x more code than before. But here's the problem I keep seeing with teams I talk to: while AI has accelerated code creation, human review capacity has remained completely flat.

This mismatch has created what I call the "Review Gap." Your team is writing more code than ever, but you're still reviewing it the old way, one PR at a time, with the same limited human attention. Pull requests pile up. Context switching increases. Deployment velocity suffers.

The solution isn't to hire more reviewers or work longer hours. The solution is to apply AI to the review process itself. Modern AI code review tools have evolved far beyond simple linters. They provide context-aware analysis that can summarize changes, catch subtle bugs, verify architectural alignment, and even suggest fixes, all in seconds rather than hours.

But not all AI review tools are created equal. I tested the leading options based on three critical criteria:

Context awareness: Does it understand your entire repository, or just the lines that changed?

False positive rate: Does it waste your time with nitpicks, or does it flag genuinely important issues?

Workflow integration: Does it fit naturally into your development process, or is it just another noisy bot cluttering your PR timeline?

Let's look at the six best tools available in 2025.

1. Graphite Agent (Best Overall Platform)

Category: Comprehensive review platform

Why it wins: Graphite solves the root cause of slow reviews (workflow) and applies AI on top.

Most AI code review tools are bots that bolt onto your existing GitHub workflow. They leave comments, generate summaries, and hope for the best. Graphite takes a fundamentally different approach. It's a platform that rethinks the entire code review workflow, starting with how you structure your changes.

Graphite's killer feature is stacked pull requests. Instead of creating one massive PR with 2,000 lines of changes, you break your work into small, atomic PRs that build on each other. Each PR in the stack is focused and reviewable. This approach dramatically improves review speed and quality, but here's the AI advantage: smaller PRs give AI dramatically better results.

When Graphite Agent reviews a 200-line PR with a clear scope, it can provide genuinely useful feedback. It catches type errors, identifies potential race conditions, spots security vulnerabilities, and suggests optimizations. When competitors try to review a 2,000-line monolithic PR, their AI struggles with context and produces generic advice or misses critical issues entirely.

Graphite Agent isn't just a comment bot. It's an interactive companion that lives on your PR page. You can ask it questions like "What happens if this API endpoint receives a null value?" or "Is this change thread-safe?" It generates test plans, explains complex logic, and provides instant summaries of what changed and why.

The integration feels seamless. Graphite Agent appears directly in Graphite's PR inbox, which provides a cleaner, faster interface than GitHub's native UI. Reviews happen in under 90 seconds. The AI maintains a sub-5% negative feedback rate, meaning developers trust its suggestions because they're rarely wrong.

Pricing is straightforward and team-friendly. Graphite Agent is included in paid plans. The Team plan runs around $40 per user per month with unlimited AI reviews, making it cost-effective for organizations that review hundreds of PRs weekly.

Best for: Teams who want to fundamentally speed up their development velocity, not just add a bot to GitHub.

2. GitHub Copilot (Best for IDE Integration)

Category: IDE and native GitHub integration

Overview: The default choice for many teams. GitHub Copilot excels at "in-the-flow" assistance while writing code.

GitHub Copilot started as an autocomplete tool but has expanded into code review territory. If you're already using VS Code with Copilot, you get basic PR review features built in. Copilot can generate PR descriptions, summarize changes, and leave inline comments on pull requests through GitHub's native interface (especially with the Enterprise tier).

The main advantage is deep integration with the Microsoft ecosystem. Copilot works seamlessly in VS Code, integrates with GitHub Enterprise, and meets enterprise compliance requirements out of the box. For organizations heavily invested in Microsoft tooling, this integration is valuable. You get a single vendor, unified billing, and consistent security policies across development tools.

The "Copilot Workspace" feature allows developers to describe desired changes in natural language, and Copilot suggests code modifications. This works well for small refactoring tasks or implementing simple features. The AI has improved significantly over the past year and can handle increasingly complex requests.

That said, Copilot's PR review experience has notable limitations compared to specialized agents. The analysis often stays surface-level, focused on style and obvious bugs rather than architectural concerns or subtle logic errors. Early adopters report that Copilot's PR comments can be noisy if not carefully configured. The AI doesn't have the same "agentic" feel as specialized tools. It provides suggestions but lacks the deeply interactive, conversational interface that helps developers dig deeper into complex issues on the PR timeline itself.

Pricing varies by plan. GitHub Copilot Individual is $10 per month, while Copilot Business is $19 per user per month. Organizations paying for GitHub Enterprise receive the most advanced PR summarization and review features as part of their contract.

Best for: Teams fully committed to the Microsoft ecosystem who want a safe, baseline AI experience without changing their workflow.

3. CodeRabbit (Best Standalone Bot)

Category: Third-party PR bot

Overview: A popular tool that connects to GitHub, GitLab, or Bitbucket and provides detailed AI reviews through PR comments.

CodeRabbit has established itself as the leading third-party AI review bot. It offers a rich feature set that goes well beyond basic static analysis. When you open a PR, CodeRabbit automatically generates a detailed "walkthrough" summary explaining what changed and why. It uses a combination of large language models and traditional linters (it runs over 40 different code analyzers) to provide comprehensive feedback.

The chat interface is a standout feature. You can have a conversation with CodeRabbit directly in PR comments, asking follow-up questions or requesting clarification on its suggestions. This makes the review process more interactive and helps developers understand the reasoning behind each recommendation.

CodeRabbit is highly configurable. You can tune its "nitpickiness" level, define custom rules for your codebase, and train it to learn from your team's feedback over time. It integrates with multiple platforms (GitHub, GitLab, Bitbucket, Azure DevOps) and offers both cloud and self-hosted deployment options for teams with strict security requirements.

The main drawback is noise. CodeRabbit leaves many comments on each PR. While comprehensive analysis can be valuable, it also clutters the GitHub timeline and can overwhelm developers, especially on larger changes. You'll need to invest time in configuration to dial down irrelevant feedback. Some teams report that CodeRabbit's enthusiasm for suggesting improvements, while well-intentioned, creates review fatigue.

Pricing is competitive. CodeRabbit offers a free tier for open-source projects and personal use. Paid plans range from $12 per user per month(Lite) to $24-$30 per user per month (Pro). The Pro tier includes all features: advanced linters, chat capabilities, and detailed reporting.

Best for: Teams who want to keep the native GitHub UI but need better automated feedback, and who don't mind investing time in configuration.

4. Greptile (Best for Deep Context and RAG)

Category: Specialized context engine

Overview: Focuses heavily on understanding your entire codebase, not just the diff in each PR.

Greptile takes a unique approach to AI code review by building a comprehensive knowledge graph of your entire repository. It indexes every function, every dependency, every historical change, and uses this context to provide unusually deep analysis. When reviewing a PR, Greptile doesn't just look at the changed lines. It understands how those changes ripple through your entire codebase.

This approach excels at answering complex questions that require cross-file or cross-module understanding. For example: "How does this API change affect the billing service?" or "What other components depend on this function?" Greptile can trace dependencies, identify potential breaking changes, and spot issues that would be nearly impossible for a human reviewer to catch without hours of investigation.

The tool is particularly valuable for large, legacy codebases where understanding context is the hardest part of code review. New team members benefit enormously from Greptile's ability to explain how different parts of the system interact. Senior engineers appreciate having an AI that can flag subtle architectural issues that simple diff-based analysis would miss.

Greptile emphasizes customization and enterprise features. You can define private AI models, create custom rules specific to your organization, and deploy Greptile on-premises for complete control over your data. The tool meets SOC 2 compliance standards and integrates with both GitHub and GitLab.

The trade-off is complexity. Greptile's full-repository analysis takes time to set up and requires more computational resources than simpler diff-based tools. The platform is priced for enterprise use at around $30 per user per month for cloud deployment, with custom pricing for self-hosted options. For smaller teams or simpler codebases, this may be more powerful than necessary.

Best for: Large, complex monorepos where understanding the impact of changes across the entire system is the hardest part of code review.

5. Ellipsis (Best for Automated Fixes)

Category: Action-oriented agent

Overview: An AI agent that can take reviewer comments and automatically implement the requested changes.

Ellipsis bridges the gap between review and implementation. Most AI review tools identify issues and leave comments. Ellipsis goes further: it can read a reviewer's comment ("Make this variable const" or "Add input validation here") and automatically generate a commit with the fix.

This capability is genuinely useful for reducing the back-and-forth in code reviews. Instead of the original author context-switching back to their IDE, finding the file, making the change, and pushing a new commit, Ellipsis handles it automatically. For minor refactoring tasks, style fixes, or simple logic adjustments, this saves significant time.

The tool works by maintaining a detailed understanding of your codebase and coding standards. When it receives a request to implement a change, it generates the code, runs tests to verify nothing breaks, and commits the result. You can review and approve the change before it's applied, maintaining control over what gets merged.

Ellipsis integrates with GitHub and supports multiple programming languages. The AI is trained on millions of open-source repositories, giving it broad knowledge of common patterns and best practices. It's particularly effective for teams that follow consistent coding conventions, as the AI can learn and replicate those patterns.

The limitations are predictable: Ellipsis handles simple, mechanical changes well but struggles with complex logic or architectural refactoring. It works best as a junior engineer who can take clear direction and implement straightforward fixes. For ambiguous or high-complexity changes, human implementation is still necessary.

Pricing has recently shifted to a seat-based model. Ellipsis charges $20 per user per month for unlimited usage, moving away from previous per-commit pricing structures. This makes it predictable for teams to adopt.

Best for: Teams who spend too much time on minor refactoring cycles and want to automate the implementation of simple reviewer feedback.

6. BugBot by Cursor (Best for Security and Logic Errors)

Category: Specialized defect detection

Overview: A tool trained specifically to find logic bugs and security vulnerabilities, developed as part of the Cursor ecosystem.

BugBot takes a surgical approach to code review. Instead of trying to do everything, it focuses exclusively on finding critical bugs and security issues. It's designed to act as a "pre-merge safety net" that catches hard-to-spot problems before they reach production.

The tool excels at identifying edge cases, race conditions, null pointer exceptions, and security vulnerabilities. It's particularly effective at reviewing AI-generated code, where subtle logic errors are more common than with human-written code. BugBot's analysis is highly precise. It maintains a low false-positive rate by focusing only on genuinely problematic code rather than style issues or minor optimizations.

BugBot is deeply integrated with the Cursor IDE. When it flags an issue, you can jump directly to the problematic code in your editor and apply the suggested fix with one click. The tight IDE integration makes the review-fix-verify cycle extremely fast.

The main limitation is scope. BugBot doesn't generate PR summaries, doesn't provide architectural feedback, and doesn't help with code documentation or readability. It has one job: find critical bugs. For teams that need comprehensive review assistance, BugBot would need to be paired with other tools.

Adoption requires committing to the Cursor ecosystem. If your team uses VS Code, IntelliJ, or other editors, switching to Cursor represents a significant change. Some developers love Cursor's AI-first features, others prefer their existing tools.

Pricing is currently tied to your Cursor subscription. It's generally included in Cursor's paid plans (Pro/Business) which start at $20 per user per month, rather than being sold as a standalone bot.

Best for: High-compliance industries or mission-critical codebases where preventing logic errors and security vulnerabilities is paramount, and teams willing to adopt the Cursor IDE.

Comparison Table: At a Glance

Tool	Primary Focus	Context Awareness	Pricing Model	Best Use Case
Graphite Agent	Complete platform (workflow + AI)	PR diff + relevant context	$40/user/month	Teams wanting to fundamentally improve velocity
GitHub Copilot	IDE integration + basic PR review	Limited to diff	$19/user/month (Business)	Microsoft ecosystem commitment
CodeRabbit	Comprehensive PR bot	PR diff + linters	$12-30/user/month	Teams keeping native GitHub UI
Greptile	Deep codebase analysis (RAG)	Full repository graph	$30/user/month	Large monorepos, complex dependencies
Ellipsis	Automated fix implementation	PR diff + coding standards	$20/user/month	Reducing refactoring cycles
BugBot	Critical bug detection	PR diff focused on logic/security	Included in Cursor Sub ($20+)	High-compliance, mission-critical code

How to Choose the Right Tool

For pure speed and workflow improvement: Choose Graphite. The combination of stacked PRs and integrated AI provides the fastest path from code complete to merge. You're not just adding AI to a slow process, you're fixing the process itself.

For massive monorepo querying: Choose Greptile. If your biggest challenge is understanding how changes ripple through a large, complex codebase, Greptile's full-repository analysis provides unmatched context.

For simple summaries on GitHub: Choose CodeRabbit or GitHub Copilot. If you want to keep your existing workflow and just add AI feedback, either of these bots will provide useful suggestions without requiring major changes to how your team works.

For mission-critical bug prevention: Choose BugBot (Cursor). If you're in a regulated industry or working on code where bugs have severe consequences, BugBot's laser focus on critical defects provides valuable protection.

For reducing trivial back-and-forth: Choose Ellipsis. If your reviews are slow because of many small fix requests, having an AI that can implement those fixes automatically saves significant time.

Conclusion

AI code review tools are no longer optional. They're essential for handling the volume of code being generated today. The Review Gap is real, and it's growing. Teams that don't adopt AI assistance will find themselves increasingly unable to keep up with the pace of development.

That said, not all AI tools address the underlying problem. Most are bots that add automation to a fundamentally slow, inefficient workflow. They help, but they're band-aids on a broken process.

To truly fix code review, you need a platform that incentivizes better practices (smaller, more focused PRs) and reviews them with AI. That's why Graphite stands out. It's not just an AI reviewer, it's a complete rethinking of how code review should work in the age of AI-accelerated development.

The best teams are shipping faster than ever while maintaining higher code quality. They're doing it by combining better workflow practices with AI assistance. If you're still relying on manual reviews of large, monolithic PRs, you're leaving velocity and quality on the table.

Try Graphite Agent today — it's included in every Graphite plan. Sign up and review your first stack in minutes.

How to use Cursor to Generate API Testcases in Requestly

Aniket Bhattacharyea — Thu, 27 Nov 2025 14:02:16 +0000

API testing is one of those tasks every developer knows is essential, but few enjoy. Manually writing test cases for every endpoint is repetitive, error-prone, and consumes valuable time that could be spent building features. Edge cases are often skipped, test coverage suffers, and teams frequently find themselves maintaining brittle scripts.

That’s where automation changes the game. By pairing Cursor, an AI-powered coding assistant, with Requestly's local-first API testing and mocking platform, you can offload the grunt work of writing tests to AI while keeping execution secure and reproducible on your own system. In this article, we’ll walk through how to set up Cursor with Requestly, generate test cases automatically, and run them end-to-end so that you can focus less on boilerplate and more on shipping features.

Why Automate API Test Case Generation?

Traditionally, writing API test cases involves manually scripting tests using the request and response schema. This process is slow, error-prone, and often results in incomplete coverage because developers don’t have time to test every possible scenario.

The challenges include:

Manual scripting overhead: Every endpoint and method must be coded by hand.

Incomplete coverage: Edge cases and negative tests are frequently skipped.

High setup cost: Establishing a reusable test framework requires a significant amount of time.

This is where Cursor provides a significant advantage. Because it’s an AI-powered coding assistant, Cursor can quickly generate test cases based on endpoint definitions, documentation, or even just example payloads. It understands context and can suggest multiple variations, including edge and error scenarios, without requiring hours of manual coding.

With Requestly's Local Workspaces, integrating Cursor becomes a breeze. Thanks to the local workspaces, all your requests are stored in the local filesystem as JSON files. For example, the following request:

becomes a JSON file:

{
  "name": "Login",
  "request": {
    "type": "http",
    "url": "{{base_url}}/user",
    "scripts": {
      "preRequest": "",
      "postResponse": "rq.test(\"Request is successful (2XX)\", () => {\n rq.response.to.be.ok\n});"
    },
    "method": "GET",
    "queryParams": [],
    "headers": [],
    "body": null,
    "contentType": "text/plain",
    "auth": {
      "currentAuthType": "INHERIT",
      "authConfigStore": {}
    }
  }
}

Note that the post-response script is stored in the scripts.postResponse key as a string.

Unlike other Cloud-based tools like Postman, the local nature of Requestly means you can feed the files directly to Cursor, and Cursor can generate test cases and edit the files. These files can be checked into version control. With this setup, teams can automate the generation of API tests, and can collaborate and review the test files, thereby saving a huge amount of time.

API Testing with Requestly and Cursor

As an example of a practical API to test, we'll be using the GitHub REST API.

To follow along with this tutorial, you'll need:

Git installed on your computer.
A GitHub Personal Access Token (PAT). Choose a repository where you have write access and give it read-write access for issues.
The Requestly desktop app.
Cursor.

Setting up Requestly

I have already created a repo that contains a Requestly collection. Clone the repo to your machine.

Start Requestly and click on the Workspaces dropdown in the top-left corner and select + Add. Select the directory where you cloned the app, and write requestly-demo as the name of the workspace. This will load the workspace of the same name that already exists in the directory.

Once the workspace is ready, navigate to the APIs tab, where you'll find the prepared GitHub API collection. In the Environments tab, you'll find an Environment named "Dev". Update the variables with your credentials:

token: Your PAT
owner: Your GitHub username
repo: The name of the repo that you chose

Note: Since the environments store the PAT in plaintext, It's recommended to add the requestly-demo/environments directory to .gitignore. Or, you could use a pre-commit hook to remove the PAT from the environment JSON upon commiting.

Setting up Cursor Rules

By default, Cursor can generate test cases for requests, since Requestly uses the commonly used Chai.js syntax. However, Requestly adds a few syntactic sugars and abstractions on top of the Chai.js library. We can inform Cursor about these features and provide it with some instructions by creating a project rule.

Create a .cursor directory in the root of the project and create a file named test-rules.mdc inside it with the following content. These instructions tell Cursor everything it needs to know for generating tests.

As you can see, we have iterated on some of the testing features provided by Requestly and have also provided some custom instructions. The globs: requestly-demo/**/*.json line tells Cursor to automatically load this rule whenever you're working with one of the Requestly files.

Since we're using the GitHub API, which is a well-documented public API, Cursor is already aware of the request and response structures. However, if you're testing your own API, it's a good idea to let Cursor know about your schemas by referencing your OpenAPI specification file. You can reference files in the rules by using @filename. For example, you can add a line like so:

Use the OpenAPI specification for request and response structure: @schema.json

Generating Tests with Cursor

Now that the Cursor rules are in place, let's test it out. Open the requestly-demo/GitHub REST API/a862b625-82ce-4ad2-9c41-4cda55e1bb5e.json file, which creates an issue in your repo.

Write "Generate test cases for this request. Show the test cases in this window before editing the file. Wait for my confirmation before editing the file" and hit enter.

Cursor will generate a few test cases and show you in the chat window.

It's a good idea to check that the test cases satisfy your expectations before writing them to the file. You can also ask it to add new tests, or change/remove any test you want. Once you're happy, ask it to update the file. Cursor will stringify the tests and write it in the scripts.postResponse key.

Accept the changes so that the file is updated.

Running the Tests

Go back to the Requestly Window and open the Create issue request. Navigate to the Scripts> Post-response tab, and you should see the tests Cursor just generated!

Note: If the tests don't appear in Requestly, you may need to reload the workspace.

Click on Send to run the tests. You should see the tests pass. Now you’ve got tests running without writing a single line by hand.

Iterate and Improve

As with any AI tool, Cursor can make mistakes and may generate a faulty test. Additionally, your API can evolve over time, and your tests may need to be updated accordingly. Simply provide feedback to Cursor and ask it to update the tests. For example, in the tests Cursor generated for me, it included checks for various fields, such as id, number, and so on. I can ask it to only check for the title and body fields.

The updated tests now only check for title and body.

Similarly, if the AI generates a faulty output (for example, a malformed JSON), you can prompt it to fix the mistake, and repeat this process until you get what you want.

Scaling and Bulk Automation

You saw how Cursor can help you generate and refine test cases. However, if you have a large number of endpoints, it's not feasible to repeat this process for each endpoint one by one. In this situation, you can use the Cursor CLI to generate tests in bulk. This process has the added benefit that you can integrate with a file watcher, like fswatch, or a Git pre-commit hook to automatically generate tests whenever the request JSON is changed. Let's see this in action.

After installing Cursor CLI, run the follwing command in the project root:

cursor-agent -p "add tests to all the requestly files in requestly-demo/GitHub REST API/. Read instructions from .cursor/rules/test-rules.mdc"

Cursor will now go ahead and add tests to all the requests.

This process has a disadvantage that you won't be able to verify the tests before Cursor writes them to the file. So, be sure to check that the tests run properly before commiting them.

Best Practices for AI-Generated API Testing

AI-assisted testing works best when you set it up for success. Cursor and Requestly make the workflow faster and safer, but the quality of your tests still depends on how you guide and maintain the process. Here are some best practices to keep your testing reliable over time:

Write Clear Prompts for Cursor

Cursor will only be as precise as the instructions you provide. Don’t just say “write a test”. Instead, specify the fields you care about, the types of responses you expect, and whether you want edge or negative cases included. For example:

"Generate tests for this request. Check for a 200 status, verify title and body fields exist, and add one negative test for unauthorized access."

The more context you give, the less cleanup you’ll need later. You can also add repetitive prompts to the project rules so that they're applied every time.

Always Review and Validate AI Output

Even with good prompts, AI may generate redundant, flaky, or irrelevant tests. Treat Cursor’s output as a draft: review it, remove what you don’t need, and refine. Requestly makes this easy since tests are just JSON with embedded scripts - you can see exactly what changed before committing.

Use Requestly Mocks and Intercepts for Safer Testing

Not every test should hit the real API. For failure cases, like 500 errors or rate limits, use Requestly’s mocks and intercepts to simulate responses.

Keep Secrets Local

Never paste API tokens, passwords, or other secrets into Cursor prompts. Store them in Requestly environments and variables instead. This way, you can safely run AI-generated tests without exposing credentials. Use development credentials in the development environment and put the Requestly environments folder in gitignore to prevent accidentally committing them.

Version Control Your Tests

Because Requestly stores collections and tests as JSON files, you can commit them directly to Git. This means your team can review, track history, and collaborate on test changes just as they do with application code. Each AI-generated test case can be peer-reviewed before merging — ensuring quality and accountability as your test suite scales.

With this setup, teams can save a huge chunk of testing time, especially when managing multi-endpoint APIs with frequent updates.

Iterate Instead of One-Shot Generation

Don’t expect perfect tests on the first try. Use Cursor iteratively: generate, review, adjust prompts, regenerate. Over time, you’ll build a solid suite of reusable tests tuned to your API’s quirks.

Combine AI Speed with Human Insight

AI is great at generating lots of cases quickly, but you know your API's edge cases, failure modes, and business logic better than any model. Utilize AI for coverage and scaffolding, then supplement with human-crafted tests for the scenarios that truly matter.

Conclusion

By combining Cursor and Requestly, you can cut down on repetitive test writing while improving API test coverage. Cursor helps you quickly generate comprehensive test cases, while Requestly ensures those tests run securely in a local-first environment.

The result: faster iteration, stronger reliability, and safer execution. If you’re looking to modernize your API testing workflow, give this combination a try - you’ll spend less time writing boilerplate tests and more time building what matters.

How to ace API Testing with Requestly

Aniket Bhattacharyea — Tue, 23 Sep 2025 06:45:59 +0000

Imagine this scenario: You’re debugging an API call. The endpoint only works with production tokens, but your API testing tool insists on syncing everything to the cloud. Suddenly, your production credentials are sitting on someone else’s servers, risking potential exposure.

Most tools default to cloud-first, which can be limiting:

Your secrets live in the cloud.
Most features require an online account.
Tests aren’t versioned with your code.

With Requestly, you get a local-first experience. Your API tests run on your machine, alongside your code, version-controlled just like the rest of your workflow. Your secrets and credentials stay on your device, safe and secure.

Local-first API testing with Requestly

With cloud-first API testing tools, your sensitive information lives in the cloud. One misconfigured account, one permission too broad, and you're risking exposing your sensitive information to the world. Requestly emphasizes local-first API testing that lets developers test APIs without depending on remote setups. You run everything right on your own machine, so you can intercept requests, mock responses, or reproduce tricky edge cases in seconds, all while keeping tokens and sensitive data safe. Because it’s all local, you get fast, reliable feedback that makes debugging smoother and development less painful.

This local-first approach means your tests can be stored next to your code, under Git. By keeping your Requestly assets under Git, you gain the benefits of collaborative development: teammates can review changes through pull requests, track history with commits, and roll back to previous versions if needed. This also fits naturally into existing workflows - your API test rules evolve alongside the code they validate.

In the following few sections of this article, you'll see Requestly in action. As an example of a practical API to test, we'll be using the GitHub REST API.

API Testing with Requestly

To follow along with this tutorial, you'll need the following dependencies on your system:

Git
Latest version of Node.js and npm.
A GitHub Personal Access Token (PAT). Choose a repository where you have write access and give it read-write access for issues.

Setting up Requestly

To make things easy, I have already created a repo that contains the basic setup needed for this article. Clone the repo to your machine.

Install the dependencies:

npm install

You can either install Requestly as a browser extension or as a desktop app. You can read about the feature differences between these two versions here. For this tutorial, I'll use the desktop app, which you can download from here. So go ahead and install it.

Requestly works on the concept of Workspaces. The demo app already has a local workspace stored, which you need to load. Click on the Workspaces dropdown in the top-left corner and select + Add.

Choose the directory where you just cloned the app, and use requestly-demo as the name of the workspace. This will load the workspace of the same name that is already in the directory.

Once the workspace is ready, navigate to the APIs tab, where you'll find the GitHub API collection. I have already prepared the requests so that we can focus on writing tests in this article. However, if you want to learn more about how to make requests, you can visit the documentation.

Note: Apart from REST APIs, Requestly also supports making GraphQL requests

There is also an Environment named "Dev" where you'll need to put your credentials:

token: Your PAT
owner: Your GitHub username
repo: The name of the repo that you chose

We'll start with simple tests, then advance to schema validation and testing workflows. We'll see how to debug and handle errors, and finally, we'll mock a third-party API.

Writing Our First Test

If authentication breaks, your entire API is toast! So, we'll start by testing the Login endpoint. This will show you an example of how to handle authentication. If you click on the collection name and navigate to the Authorization tab, you'll see that the authorization type has been set to Bearer Token. For the token value, we're using {{token}}, which retrieves the value from the environment variable.

Every endpoint in this collection inherits this authentication method, which means they'll automatically pass the token when you make the request.

Open the Login request and navigate to the Scripts tab. Requestly allows you to run scripts before the request is sent (Pre-request scripts), or after the response is received (Post-response scripts). For the purpose of writing API tests, we'll use the Post-response scripts.

Requestly uses Chai.js for assertions. It exposes the expect method of Chai through rq.expect(), which you can use to write assertions. Requestly also lets you access the request and response objects through rq.request and rq.response respectively, which can be used in the tests.

Our first test will make sure that the server returns 200 Ok response. Let's start by creating a test. We want to check that rq.response.status is equal to OK. So, our test will look like this:

rq.test("Login is successful", () => {
  rq.expect(rq.response.status).to.equal("OK")
})

Now, if you click on Send, Requestly will make the request and run the tests. You can see the result of the test in the Tests tab:

Requestly also allows you to check the status code using its name:

rq.response.to.be.ok

You can find all the status codes in the docs.

Testing Authentication

Now we know that the login request is successful, but how do we know that the login itself works correctly? The login endpoint also returns the logged-in user's data, which we can validate against the ground truth.

Here we can check that the login property matches our username that we put into the owner environment variable:

rq.test("Login returns valid data", () => {
  var body = JSON.parse(rq.response.body)
  rq.expect(body).to.have.property("login").that.is.a("string")
  rq.expect(body.login).to.equal(rq.environment.get("owner"))
})

Send the requests, and if everything goes correctly, you should see the tests pass.

Schema Validation

APIs act as contracts between services, and if the structure (fields, types, nesting, required attributes) changes, consumers may break, even if the data looks valid. This is why it's vital to test that the response object has the correct schema.

In the List repos request, we're making a request to the /user/repos endpoint, which fetches all the repos of the logged-in user. Let's assume that we are integrating this API with a frontend that expects the body to be an array of repos, and each repo must have id, name, private, and owner fields. The owner field must have login and id fields, and the name field must match the regex: /^\.?[a-z0-9-_\.]+$/i.

In Requestly, you can use helpers from Chai to do this:

var body = JSON.parse(rq.response.body)

rq.test("Fetched data has correct body", () => {
  // Check that body is an array
  rq.expect(body).to.be.an("array").that.is.not.empty

  for (let repo of body) {
    // Check required fields
    rq.expect(repo).to.include.keys(["id", "name", "private", "owner"])
    rq.expect(repo.owner).to.include.keys(["login", "id"])

    // Match regex
    rq.expect(repo.name).to.match(/^\.?[a-z0-9-_\.]+$/i)
 }
})

This test works, but it's very verbose. If you have a more complicated JSON schema, you'll have to spend a lot of time writing out each property one by one. This is also unmaintainable. If the schema changes, changing it in the test will feel like finding a needle in a haystack. You can use .to.have.jsonSchema instead, which lets you pass a JSON schema.

For example, you can write the above test:

rq.test("Match JSON schema", () => {
  rq.response.to.have.jsonSchema({
  type: "array",
    items: {
      type: "object",
      required: ["id", "name", "private", "owner"],
      properties: {
        id: { type: "number" },
        name: { type: "string", pattern: "^\\.?[a-zA-Z0-9-_\\.]+$" },
        private: { type: "boolean" },
        owner: {
          type: "object",
          required: ["login", "id"],
          properties: {
            login: { type: "string" },
            id: { type: "number" }
          }
        }
      }
    }
 })
})

This is much easier to write, understand, and maintain. Of course, let's make sure the tests work.

Testing Complete Workflows

Often, your API calls are not as simple as calling one single endpoint. You might need to call one endpoint, process the response, and use the data from the response to call another endpoint. With Requestly, you can use Environment Variables to store arbitrary data and use them in subsequent requests. We have already used one environment variable in the Login endpoint. Let's now take a look at a more complete "workflow" example.

Let's assume that we want to test the pipeline of creating, fetching, and deleting issues. We want to create an issue, fetch the same issue, and then delete it.

In the Create issue endpoint, we're making a request to {{base_url}}/repos/{{owner}}/{{repo}}/issues endpoint. The {{...}} denotes an environment variable that Requestly will substitute. We're creating an issue with the following body:

{
  "title": "Test issue from Requestly",
  "body": "This is a test issue created via API"
}

Let's write a test to ensure the issue is created successfully:

rq.test("Issue was created successfully", () => {
  rq.response.to.be.created
  rq.response.to.have.jsonBody("title", "Test issue from Requestly")
  var body = JSON.parse(rq.response.body)
  rq.environment.set("issue_id", body.number)
})

Here, we're checking that the title of the issue matches what we sent in the body. The last line is where we set the issue_id environment variable, which we'll use in our subsequent request.

Open the Fetch issue request. You'll notice we're using the issue_id in the request URL: {{base_url}}/repos/{{owner}}/{{repo}}/issues/{{issue_id}}.

Let's write a test to verify the correct issue is fetched. We'll verify that it has title and body fields, and matches what we created:

rq.test("Issues has correct schema", () => {
  rq.response.to.have.jsonSchema({
    type: "object",
    required: ["title", "body"],
    properties: {
      "title": { type: "string" },
      "body": { type: "string" }
    }
  })
})

rq.test("Fetches correct issue", () => {
  rq.response.to.have.jsonBody("title", "Test issue from Requestly")
  rq.response.to.have.jsonBody("body", "This is a test issue created via API")
})

Finally, let's close the issue to complete the workflow. In the Close issue request, you'll see we're again using the issue_no variable. This time, let's make sure state is closed in the response:

rq.test("Issue is closed", () => {
  rq.response.to.have.jsonBody("state", "closed")
})

You can use this technique of chaining requests in many real-life scenarios. For example, if your API uses username and password to log in and returns a JWT, you can store it in an environment variable and use it in subsequent tests.

Error Handling and Debugging

So far, we've been dealing with tests that work correctly. But in practice, tests may fail. And it's not always easy to debug. Suppose the login test is suddenly failing in CI. Is it because someone pushed buggy code, or is it due to something in the test itself, such as an expired token? Requestly offers debugging features to help you understand why your tests are failing.

When a test fails, Requestly prints an error message next to the test. You can try this out by sending the Invalid token request. This request attempts to log in with an invalid token, but expects the result to be 'ok'.

You can also use console.log to log values. You can use rq.request and rq.response objects to access the request and response values to help you debug the actual cause of a failing test. For example, let's log the request headers and response status code:

rq.test("Reuest is successful", () => {
  console.log(JSON.stringify(rq.request.headers))
  console.log(rq.response.status)
  rq.response.to.be.ok
})

When you press Ctrl+Alt+I, the Devtools console will open. If you send the request, the logs will show up.

These logs can help you debug your test.

Mocking & Intercepting for API Testing

We’ve seen how to handle real errors like bad tokens or missing endpoints. But what about failures that don’t happen on their own? For example, a flaky third-party API or an edge case response you can’t easily trigger in production. That’s where mocking comes in.

Real apps often depend on third-party APIs, such as payment processors, weather data, and analytics. Testing these integrations is tricky because:

You can’t control when the third-party API fails.
You can’t control the data it sends back.
Sometimes, every test call costs real money.

This is where API mocking helps. With Requestly, you can intercept an outgoing request and return a fake response. That way you can simulate failures, edge cases, or alternate data without touching the real API.

Our demo repo has a /httpbin endpoint that calls http://httpbin.org/get. Normally, it just passes through the response. But what if HttpBin goes down? We want to see if our app handles errors gracefully.

To mock an API call, you need to use Requestly's HTTP interceptor, which turns Requestly into a proxy server to intercept HTTP calls from your browsers (Chrome, Firefox, etc.), terminal app, or even the whole system. Then you can use HTTP rules to modify the request, response, headers, introduce delays, redirect, and much more.

As of writing this article, this feature is not available in a local workspace. So, you'll need either a team workspace or switch to the private workspace. In any case, you'll need an account. Click on the icon in the top-right corner, and sign up or sign in.

Now in the workspace dropdown menu, you'll see that the Private workspace option is enabled. Choose this option to switch to the private workspace.

Go to the Network tab, click on Connect apps, switch to the Terminal processes tab, click on Setup instructions, and copy the command.

Paste the command in the terminal and run it. On successful execution, you should see the message Requestly interception enabled. Now start the server with npm start. Now, any request made from the API server will pass through Requestly.

Note: Running the command provided by Requestly sets up a few environment variables, one of them being https_proxy, which sets up Requestly as a proxy server. The demo app uses Axios to make requests to HttpBin. Axios automatically picks up the https_proxy environment variable, so in this case, we don't have to change any code. However, suppose you use a different library (such as node-fetch) that doesn't automatically pick up the https_proxy environment variable. In that case, you'll need to modify the code to use the proxy server manually.

In another terminal, invoke the /httpbin endpoint:

curl localhost:3000/httpbin

In Requestly, you should see the HttpBin request show up:

Note: As of writing the article, requests made with Axios show up with the wrong URL due to a bug.

Right-click on it and select Modify response body.

This will open a window where you can define an HTTP rule that will modify the response body of the intercepted request.

First, give the rule a name, for example: "HttpBin error". In the If request field, select URL and Contains and write httpbin.org in the input field. Select 500 from the status codes dropdown, enter an empty body, and check Serve this response body without making a call to the server. Then, save the rule.

Now, anytime our API server makes a request to HttpBin, Requestly will return a 500 response without actually hitting HttpBin.

Let's now write the test. Go to APIs tab, and create a new HTTP request. Provide a name such as Get third party error, and put http://localhost:3000 in the URL field, and write the test:

rq.test("Should return error", () => {
  rq.response.to.have.status(500)
})

Now I can test whether my app correctly handles failures or not without having to wait for the third-party API to fail!

With these tests in place - from happy paths to deliberate failures - we've covered the core scenarios of real-world API testing. Now it's your turn to use Requestly for testing your APIs.

Conclusion

Effective API testing goes beyond checking if an endpoint returns data - it ensures reliability, catches edge cases, and streamlines development. By going local-first with Requestly, you can quickly test and mock APIs without juggling cloud accounts or heavy setups. Start small with a few tests, then layer on more complexity as your needs grow. The best way to see the value is to try it in your own workflow and feel how much smoother debugging and iteration can become.

(Almost) Everything You Need To Know About Pointers in C

Aniket Bhattacharyea — Thu, 09 Sep 2021 07:09:05 +0000

When I was first starting out with C, pointers were something that confused me the most. I was scared of pointers and could never understand how to use them.

No, I didn't say that! In fact, pointers have always been intuitive to me. But most of the students starting to learn C are put off by the idea of pointers. It is one of those areas of C which are not explained properly to students. resulting in many misconceptions about them.

In this huge post, I have compiled almost everything that is fundamental to pointers. Of course, it is a huge topic, and it's not possible to cover the entirety of it in one post, but once you know these fundamentals, you'll be able to use them more efficiently, and hopefully will be able to tackle pointers in a program.

Let's start.

Beginning With Pointer Sorcery

One fine afternoon, you are lying on your couch and thinking about the year 2038 problem and the end of the universe, and suddenly your friend calls you and asks "Hey, I want to come over and contemplate our existence, but I do not know where your house is!"

You say, "No problem buddy. I'll give you a copy of my home."

Of course, you'd never say that. Instead, you will give him your address so that he can come over. Now, you could make him a copy of your home if you're generous enough, but it takes time and defeats the purpose of your friend coming over. He wants to come to your house, not a copy.

Now think in terms of programming. At the time when C was created, memory was scarce, and being efficient was not only needed but vital. For this reason, you'd have to be really careful while dealing with memory. You'd really not like to make unnecessary copies of something.

Another case you can consider is of having "side effect" of a function. Consider this simple program.

#include <stdio.h>
void f(int a) { a = 10; }
int main() {
    int a = 5;
    printf("%d\n", a);
    f(a);
    printf("%d\n", a);
}

which just prints

5
5

Even though you are calling the function f with the variable a as a parameter, and f is changing the value of a. the change doesn't show up in the original value of a, because when you are calling the function f, you are passing a copy of a, not a itself. In other terms, you are giving your friend a copy of your house.

This is desired in most cases. You don't really want your functions to accidentally change any variable where it's not supposed to. But sometimes, you actually want the function to change a variable. You have already seen such a function that can change the actual parameter.

scanf("%d", &n);

How does scanf change the value of n? The answer is through pointers.

Also, take a look at this classic example of swap-

void swap(int a, int b) {
    int t = a;
    a = b;
    b = t;
}
int main() {
    int a = 5, b =10;
    swap(a, b);
    printf("a = %d, b = %d\n", a, b);
}

It works, except it doesn't.

swap does swap the variables, but since you are making a copy of a, and b, the change doesn't show up outside the function. But we want the function to be able to change the actual variables. So we need to have some kind of way to pass the actual a and b . But in C, there is no way you can pass "actual" variables. (which is not the case in C++).

One way you might end up doing is to make a and b global

int a = 5, b = 10;
void swap() {
    int t = a;
    a = b;
    b = t;
}
int main() {
    swap();
    printf("a = %d, b = %d\n", a, b);
}

And it now works, because swap now can access a and b, but having global variables is a real bad idea.

The way? Give swap the addresses of a and b. If it has addresses of a and b , it can change them directly.

Pointers are nothing but variables that hold the address of another variable.

Now, where does this address come from? We know how bits and bytes work. The RAM of the computer can be thought of as a mess, a really long one, with lots of rooms one after another, and each byte is a room. How does the computer know which room to put data in? It gives a number to each room, and that number is the address.

When I write

char a;

I tell the compiler "Buddy, reserve one room in the mess, and call it a" . Why one room? Because the size of char is 1 byte. (Note that C's definition of a byte is basically the sizeof char , which in some rare cases might not be actually 1 byte in the machine, however, it is always 1 byte in C)

If I write

int b;

I tell the compiler to reserve the number of rooms necessary for int and call it b.

Side rant: People coming from Turbo C, and being told size of int is 2 bytes, it's not necessarily so, and probably not so in any modern computer. The C standard guarantees at least 2 bytes for int and on my machine sizeof(int) is 4, so we will stick to that for the rest of this post.

Now that our b has 4 rooms, it will stay in the rooms starting from the first one. So that when we say "address of b", we actually mean "address of the starting or ending byte of b". (See big endian and little endian. For this tutorial, let's assume it's the ending byte because it is so on my machine)

In order to get the address of b and store it, we need to use a pointer variable. Just like any other variable, a pointer also has a type, defined by the type of the thing it points to. The syntax is type_of_the_thing_it_points_to *name

char *pa;

Note that the asterisk need not be adjoined to the variable name. Any of these is valid -

char* pa;
char *pa;
char * pa;

We will prefer the 2nd syntax. We will see in a short while why.

Let's first see how to assign a value to a pointer. In order to make a pointer point to a variable, we have to store the address of the variable in the pointer. The syntax for getting the address of a variable is &variable_name.

char a;
char *pa = &a; // pa now contains the address of a

printf("%p", pa); // %p is the format specifier to print a pointer

If you run this program, you will see something like 0x7ffc2fc4ff27. That is the value of the pointer, which is the address of the variable a (this is in hexadecimal). This value is not fixed. If you run the program again, the value will likely change, because a will be stored somewhere else.

One thing you might have noticed. Although we are declaring it as *pa, the * is not used when printing the pointer. In fact, * is not a part of the name of the pointer. The name of the pointer is just pa. The * is instead used to get the value of whatever thing the pointer is pointing to (known as dereferencing).

char a = 'a';
char *pa = &a;

printf("%p\n", pa); // prints the value of pa
printf("%c", *pa); // prints the value of a

So, quickly revise -

pa is the value of the pointer, which is the address of a.
*pa is the value of the thing pa is pointing to, in this case a.

One more time.

pointer_name is the value of the pointer itself.
*pointer_name is the value of the thing the pointer points to.

Now, this should be clear.

char a = 'a', b = 'b';
char * pa = &a; // pa points to a
*pa = 'c'; // change the value of whatever pa is pointing to, in this case a
printf("%c", a); //prints c
pa = &b; // change the pointer itself. pa now points to b
*pa = 'd' // change the value of whatever pa is pointing to, in this case b
printf("%c", a); //prints c, because a is unchanged as pa is no more pointing to a
printf("%c", b); //prints d

Now we can rewrite the swap function as follows -

void swap(int *a, int *b) {
    int t = *a;
    *a = *b;
    *b = t;
}

And call it with the addresses swap(&a, &b). This works and the change shows up outside the function too. Because once you have the address of a variable, you know where it lives in memory so you can freely change it.

You might have a valid question. Since all pointers are just addresses, which are basically numbers, why is the type of the thing it points to necessary? Why do we distinguish between char* and int* although both of them are just some numbers?

The answer is clear. When you dereference a pointer, the compiler needs to know what data type is the object. Remember that address of a variable is just the address of the ending byte of the variable. In order to read the variable, the compiler needs to know its type so that it knows how many bytes to read.

Consider this program

#include <stdio.h>

int main() {
    int a = 1101214537;
    char *pa = &a;
    printf("%c", *pa);

    return 0;
}

It prints (ignore the compiler warning)

What happened here?

If you represent 1101214537 in binary it is 01000001 10100011 00110011 01001001 . So &a which is the address of a points to the byte in memory that contains the last byte of the number, which is 01001001. When I dereference pa, the compiler sees that it points to char so it reads only one byte at that address, giving the value 01001001 which 73, the ASCII for I. This is why the type is absolutely and you should not mix and match types unless you are absolutely sure of what you are doing. (We'll see a few examples)

Remember we told that we will prefer int *pa rather than int* pa although they are the same? The reason is to safeguard against the following common misconception. Can you find the difference?

int a, b; // a and b both are int
int* pa, pb; // whoopsie! pb is not a pointer

If you are a beginner, you will assume that since int a, b makes both a and b as int , then int* pa, pb will make both pa and pb as int*. But it doesn't. The reason is * "binds" to the variable name, not the type name. If instead, you'd have written

int *pa, pb;

you'd rightly conclude pa is a pointer to int, and pb is just int. Hence I prefer to write the * with the variable name, however, there are compelling reasons for the other style as well, and if you are careful enough, you can use the other style as well.

NULL and void pointer

These two are a special types of pointers in C. The Null pointer is used to denote that the pointer doesn't point to a valid memory location.

int *pa = NULL;
char *pb = NULL;

We use Null pointer in various ways, for example, to denote failure, or mark the end of a list of unknown size, etc. Dereferencing a Null pointer is undefined behavior and your program will likely crash.

Note that the Null pointer is not the same as pointer to memory address 0, although it's very likely to be so. There are exceptions, for example in small embedded devices where address 0 might be a valid location.

Void pointer is one more interesting pointer in C. Basically void pointer "throws away" the type of a pointer. It is a general-purpose pointer that can hold any type of pointer and can be cast to any type of pointer. The following are all valid -

int a;
char b;
float c;
void *p = &a;
p = &b;
p = &c;

But you can't dereference a void * because it doesn't have a type. Trying to dereference a void * will give you an error. However, you can cast it to anything you want and then dereference it, although it's not a very good idea and it violates the type aliasing rules.

int a = 65;
void *p = &a;
char *c = (char *) p;
printf("%c\n", *c);

Here we're removing the type of &a through p and casting it to a char *. Essentially a is getting read as a char and this prints A.

Be careful during casting. You should use void pointers only if you are absolutely sure of what you're doing.

int a = 65;
void *p = &a;
int (*f)(int) = (int (*)(int)) p; // cast as a function pointer (discussed later)
f(2); // Segmentation fault

Sometimes you'll see char * used as a generic pointer as well. This is because void * was not present in old versions of C, and some practice remains, or maybe the code needs to do pointer arithmetic on that pointer.

Generally void *is used in places where you expect to work with pointers to multiple types. As an example, consider the famous memcpy function which copies a block of memory. Here is the signature of memcpy -

void * memcpy ( void * destination, const void * source, size_t num );

As you see, it accepts void *, which means it works with any type of pointers. As for an example (copied from cplusplus) -

/* memcpy example */
#include <stdio.h>
#include <string.h>

struct {
  char name[40];
  int age;
} person, person_copy;

int main ()
{
  char myname[] = "Pierre de Fermat";

  /* using memcpy to copy string: */
  memcpy ( person.name, myname, strlen(myname)+1 );
  person.age = 46;

  /* using memcpy to copy structure: */
  memcpy ( &person_copy, &person, sizeof(person) );

  printf ("person_copy: %s, %d \n", person_copy.name, person_copy.age );

  return 0;
}

In line 15, we invoked memcpy with char * and in line 19, we invoked memcpy with a pointer to structure, and they both work.

Pointer arithmetic

Since pointers are just like other variables, you'd expect that we should be able to do arithmetic with them. We can, but there's a catch. First of all, we are only allowed these 2 operations -

Addition (and hence subtraction) of an integer constant to a pointer.
Subtraction of two pointers of the same type.

Let's see them one by one

int a;
int *pa = &a;

printf("pa = %p\n", pa);
printf("pa + 1 = %p\n", pa + 1);
printf("pa - 1 = %p\n", pa - 1);

This prints

pa = 0x7ffdd7eeee64
pa + 1 = 0x7ffdd7eeee68
pa - 1 = 0x7ffdd7eeee60

Strangely, it seems pa+1 increments the pointer by 4, and not by 1. The reason lies in the datatype of the thing it points to, in this case, int. Remember that a pointer must always point to something. When you increment the pointer by 1, it points to the next thing.

In this case, pa points to an int. Where is the next int? After 4 bytes of course, because the size of int is 4 bytes.

Similarly pa-1 points to the previous int which lies 4 bytes before.

By the same logic, pa+2 points to the int 2 places after a that is 4 * 2 = 8 bytes after a, and pa+n points to the integer n places after a which is 4n bytes after a.

An observant reader might have noticed that things are looking almost like an array, and he/she is not wrong completely. In a few minutes, we shall explore the idea of array using pointers. Before let's talk about the subtraction of pointers.

int a;
int *pa = &a;
int *pb = pa + 2;
printf("pa = %p\n", pa);
printf("pb = %p\n", pb);
printf("pb - pa = %ld\n", pb - pa);
printf("pa - pb = %ld\n", pa - pb);

This prints

pa = 0x7ffec09d685c
pb = 0x7ffec09d6864
pb - pa = 2
pa - pb = -2

Similar to the previous case, although the difference between pa and pb is of 8 bytes as numbers, as pointers the difference is 2. The negative sign of pa-pb implies that pb points after pa.

To quickly summarise -

If I have some_data_type *p, then pa + n increments the pointer by n * sizeof(some_data_type) bytes.
If I have some_data_type *p, *q then p - q is equal to the difference in bytes divided by sizeof(some_data_type)

Let's consider what happens if we mix indirection and prefix or postfix increment/decrement operators. Can you guess what each of these does? I have omitted the data types so that you can't guess ;-). Assume p points to int

x = *p++;
x = ++*p;
x = *++p;

In order to answer, you have to remember the precedence -

Postfix ++ and -- have higher precedence than *
Prefix ++ and -- have the same precedence as *.

Since the * operator is itself a prefix, you'll never have a problem with prefix increment or decrement. You can tell just by the order of the operator. For the postfix operator, remember that postfix works first, then indirection.

So *p++ is same as *(p++). So, the value of p will be used in the expression, then p will be incremented. So x gets the value of *p and p becomes p+1, so that the type of x ought to be int too.

int a = 5;
int *p = &a;
int x;
printf("Before:\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
x = *p++;
printf("After\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
printf("x = %d\n", x);

This prints

Before:
a = 5
p = 0x7ffe82ae9eb0
After
a = 5
p = 0x7ffe82ae9eb4
x = 5

++*p will probably not arise confusion. This is the same as ++ (*p). So, first p is dereferenced, and then ++ is applied. So whatever p was pointing to gets incremented by 1 and then it is assigned to x, and p is unchanged. So the type of x is again int.

int a = 5;
int *p = &a;
int x;
printf("Before:\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
x = ++*p;
printf("After\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
printf("x = %d\n", x);

This prints

Before:
a = 5
p = 0x7fff1484e210
After
a = 6
p = 0x7fff1484e210
x = 6

And finally * ++p is same as * (++p). So, first p gets incremented by 1, and then it is dereferenced. So x gets the value of whatever is this incremented pointer pointing to.

int a = 5;
int *p = &a;
int x;
printf("Before:\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
x = *++p;
printf("After\n");
printf("a = %d\n", a);
printf("p = %p\n", p);
printf("x = %d\n", x);

This prints

Before:
a = 5
p = 0x7ffd4bad9c90
After
a = 5
p = 0x7ffd4bad9c94
x = 32765

We can also compare pointers using relational operators like ==, <= etc. but there's a catch. You can only compare two pointers using <=, <, >=, > if they both are pointers of the same type, and of the same array or same aggregate object. Otherwise, it is undefined behavior.

Quoting C11 -

When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. *In all other cases, the behavior is undefined.*

Take a look -

typedef struct some_struct {
    int p;
    int q;
} some_struct;

some_struct a = {1, 2}; 
int *p = &a.p;
int *q = &a.q;
if(p > q) puts("Hi\n");
else puts("Bye\n");

This prints Bye. Well first of all this comparison is valid since p and q are both pointers to int and also they both point to elements of the same struct. Since q was declared later in some_struct , q compares greater to p

For equality, the restriction is a bit slack. You can compare any two pointers as long as they have the same type, or one of them is a null pointer or void pointer. And they compare equal if they point to the same object, or if both are null (doesn't matter if types don't match), or if both are pointing to members of the same union.

Let's demonstrate the last point.

typedef union some_union {
    int p;
    int q;
} some_union;

some_union a;
int *p = &a.p;
int *q = &a.q;

if(p == q) {
    puts("Equal\n");
} else {
    puts("Not equal\n");
}

This prints Equal although p and q point to different things, they are within the same union.

Since pointers are just numbers, can you put any integer in them? The answer is yes, but be careful of what you put. In fact, be careful when you dereference it. If you try to dereference an invalid address, your program will likely segfault and crash.

int *x = (int *) 1;
printf("%d\n", *x);

This instantly segfaults.

Admitted to Hogwarts School Of Pointer Magic

Pointers and Arrays

Let's now move to some advanced sorcery - array and pointers.

We know that an array stores its elements contiguously in memory. Which means the elements are stored in order one after another. So if we have int arr[10], we know arr[1] lies right after arr[0], arr[2] lies right after arr[1] and so on. So if I have a pointer to arr[0] and I increment it by 1, it should point to arr[1]. If I increment it by 1 again, it should point to arr[2].

In fact, there are so many similarities between arrays and pointers, that we can talk about the equivalence of arrays and pointers.

Word of caution! This does not mean arrays and pointers are the same and you can use one in place of another. This misconception is quite common and ends up being harmful. Arrays and pointers are very different things, but pointer arithmetic and array indexing are equivalent.

For starters, the name of an array "decays" into a pointer to the first element. What do I mean by that? Consider this code -

int arr[10];
int *pa = &(arr[0]); // pointer to the first element
int *pb = arr; // What

printf("pa = %p\n", pa);
printf("pb = %p\n", pb);

This prints

pa = 0x7ffef7706bb0
pb = 0x7ffef7706bb0

But aren't we mixing up datatypes in the case of pb? pb is a pointer to int and arr is an array of int!

Turns out that arr is converted to a pointer to the first element. So that arr and &(arr[0]) is equivalent.

Quick note: indexing operator [] has higher precendence than * so that * arr[0] is same as * (arr[0])

Let's do even more funny stuff -

int arr[3] = {1, 2, 3};
int *pa = arr;


printf("arr[1] = %d\n", arr[1]); // 2nd element using array indexing
printf("*(pa + 1) = %d\n", *(pa + 1)); // 2nd element using pointer arithmetic
printf("pa[1] = %d\n", pa[1]); // What
printf("*(arr + 1) = %d\n", *(arr + 1)); // Whatt
printf("1[arr] = %d\n", 1[arr]); // Whattt

The first printf is ok. arr[1] means the 2nd element of arr.

We just reasoned about the 2nd line. pa points to the first element of arr. So pa+1 will point to the next int in memory, which is arr[1] because array elements are stored contiguously.

But in the 3rd and 4th lines, aren't we mixing up array and pointer syntax? Well, turns out that arr[i] is just the same as *(arr + i) and this is (almost) what happens internally when you write arr[i].

Similarly *(pa + i) is the same as pa[i]. Pointer arithmetic works both on arrays and pointers. Similarly, array indexing works on both pointers and arrays.

And for the last part, arr[1] is the same as *(arr + 1) which is the same as *(1 + arr) which should be the same as 1[arr]. This is one of those weird quirks of C.

Does this mean you can mix and match pointers and arrays? The answer is a big fat no. The reason is although arr[i] and pa[i] give you the same result, i. e. the 2nd element of arr, the way they reach there is quite different.

Consider the code

#include<stdio.h>
int main() {
    int arr[3] = {1, 2, 3};
    int *pa = arr;
    int a = arr[1];
    int b = pa[1];
}

Let's look at the assembly code generated by the compiler. I used Compiler Explorer. Don't worry if you can't read assembly. We'll go together.

We are interested in lines 5 and 6. Here's the related assembly for int arr[3] = {1, 2, 3}.

mov     DWORD PTR [rbp-28], 1
mov     DWORD PTR [rbp-24], 2
mov     DWORD PTR [rbp-20], 3

In case you are seeing assembly for the first time, rbp is the base pointer register that holds the memory address of the base of the current stack frame. Don't worry about what that means. For now think of rbp as a pointer variable, which points to some location in memory.

Here the contents of arr is being put in memory. For example, consider the first line. The mov instruction puts the value 1 somewhere in memory. The DWORD PTR tells that it is of size 32 bit or 4 bytes as it is an int. The syntax [rbp - 28] means the content of the memory location at the address rbp-28. Remember that rbp is like a pointer. So it is the same as doing * (rbp - 28).

Putting everything together, we see that the first line puts the value 1 in the memory address pointed by rbp-28. The next value should be stored right after it, i. e. after 4 bytes. Which should be pointed by rbp-24 and indeed that is where 2 is stored. And finally, 3 is stored in the memory address pointed by rbp-20.

So, we see that the address of the first element is rbp-28. So we'd expect this should be reflected in the line int *pa = arr;. And indeed it is -

lea     rax, [rbp-28]
mov     QWORD PTR [rbp-8], rax

lea means load effective address which calculates rbp-28 and stores the address in rax rather than fetching the content of the memory address rbp-28 and storing the content. In other words, it just copies the address of the first element in rax register and then in the memory location rbp-8 which is our pa.

Now let's look at int a = arr[1]

mov     eax, DWORD PTR [rbp-24]
mov     DWORD PTR [rbp-12], eax

So here first the content of rbp-24 is loaded into eax and then stored in rbp-12 which is our a. The interesting thing to notice is that the compiler knows the first element of arr is at rbp-28 so when you write arr[1] it directly offsets the base address by and getsrbp-24`. This happens in compile time.

Now let's look at int b = pa[1];

mov     rax, QWORD PTR [rbp-8]
mov     eax, DWORD PTR [rax+4]
mov     DWORD PTR [rbp-16], eax

Here we see first the value stored at rbp-8 is moved to rax. Remember this was our pa variable? So first the value stored at pa is read. Then it is offset by 1, so we get rax + 4 and we read the value at rax+4 and store it to eax. Finally, we store the value from eax to rbp-16 which is the b variable.

The noticeable difference is that it takes one extra instruction in case of pointer. Because array address is fixed, when you write arr, the compiler knows what you're talking about. But a pointer value can be changed. So when you write pa, the value of pa needs to be read first and then it can be used.

Now suppose something like this. You have two files. One contains a global array like

int arr[3] = { 1, 2, 3 };

And in another file, you get carried away by the equivalence of array and pointer and write

extern int *arr;

In other words, you have declared arr as a pointer but defined as an array. What will happen if you write int a = arr[1]?

The answer is - something catastrophic. Let's see why.

Let's assume the array elements are stored just like before -

mov     DWORD PTR [rbp-28], 1
mov     DWORD PTR [rbp-24], 2
mov     DWORD PTR [rbp-20], 3

But in our second file, we are doing arr[1]. So it will do something like

mov     rax, QWORD PTR [rbp-28]
mov     eax, DWORD PTR [rax+4]
mov     DWORD PTR [rbp-16], eax

Can you see the problem? We are reading the content at rbp-28, but the content is 1, the first element of the array. So, essentially we are reading the content of memory address 1+4=5 which is an invalid location!

Bottom line: Don't mix and match.

Another difference is that a pointer name is a variable, but an array name is not. So you can do pa++ and pa=arr but you cannot do arr=pa and arr++

But, there is a case where arrays and pointers are the same. That is in function parameters -

void f(int *pa, int arr[]) {
    int a = pa[1];
    int b = arr[1];
}

What is the difference between arr and pa? There is no difference

int a = pa[1]
mov     rax, QWORD PTR [rbp-24]
mov     eax, DWORD PTR [rax+4]
mov     DWORD PTR [rbp-4], eax

int b = arr[1]
mov     rax, QWORD PTR [rbp-32]
mov     eax, DWORD PTR [rax+4]
mov     DWORD PTR [rbp-8], eax

The compiler treats arr and pa both as pointers, and that's about the only case you can be certain that using pointer in place of array works.

Technically, this is an illustration of an array-like syntax being used to declare pointers, rather than an example of pointers and arrays being the same.

Since pointers are like any other variable, you can have a pointer to pointers too.

int **pa;

Here pa is a pointer to pointer to int. So, *pa will give you a pointer to int, and finally **pa will give you an int

int a;
int *pa = &a; // pointer to int
int **ppa = &pa; // pointer to pointer to int

You can have pointers to array too. But before that, remember [] has higher precedence than *

int (*pa)[3]; // pointer to array of 3 elements
int *pa[3]; // 3 element array of pointer to int

What's the difference between pointer to an array and normal pointer? Consider

int arr[3] = {1, 2, 3};
int (*pa)[3] = &arr;
int *pb = arr;

printf("arr = %p\n", arr);
printf("pa = %p\n", pa);
printf("pb = %p\n", pb);

This prints

arr = 0x7fff2632cc84
pa = 0x7fff2632cc84
pb = 0x7fff2632cc84

So, essentially they all point to the same location. And we already know arr is the same as a pointer to the first element. Now we see that &arr also contains the location of the first element.

Although pa and pb point to the same location, what they point to is very different. pb is a pointer to [int] so it points to a [int] which is the first element of arr whereas pa is a pointer to [array of 3 elements] so it points to an [array of 3 elements] i. e. the whole arr.

This is evident when you try to do arithmetic -

printf("pa + 1 = %p\n", pa + 1);
printf("pb + 1 = %p\n", pb + 1);

This prints

pa + 1 = 0x7fff2632cc90
pb + 1 = 0x7fff2632cc88

pb is a pointer to int. So pb+1 points to the next int 4 bytes after. Whereas pa is a pointer to array of 3 int. So pa+1 will point to the next array of 3 int which is 3 * 4 = 12 bytes after, and indeed, pa+1 is 12 bytes after pa. ( 0x7fff2632cc90 - 0x7fff2632cc84 = 12, these are in hexadecimal in case you're confused).

You can use a pointer to array just like a normal variable. Just remember the precedence -

int arr[3] = {1, 2, 3};
int (*pa)[3] = &arr;

int a = *pa[1]; // Wrong
int b = (*pa)[1]; // Correct

The easiest way to remember is "Declaration follows usage." So the usage of a pointer will look like the way it was defined. Since we defined pa as (*pa)[], its usage will also look the same.

One common mistake that students do, with the fact that arrays decay down to pointers in function parameters is working with multidimensional arrays.

If you have something like

int arr[3][4] = {{1, 2, 3, 4}, {5, 6, 7, 8}, {9, 10, 11, 12}};
f(arr);

you might think since array names decay to pointers in function parameter, an array of array should decay to a pointer to pointer. So you might write the declaration of f as

void f(int **m) {
    ...
}

Unfortunately, this is wrong and will give a warning (but will compile)

main.c:22:8: warning: passing argument 1 of ‘f’ from incompatible pointer type [-Wincompatible-pointer-types]                                                   
main.c:11:5: note: expected ‘int **’ but argument is of type ‘int (*)[4]’

What happened here? It's easy.

If an array of [int] decays down to a pointer to [int], what should an array of [array of int] decay down to? Of course a pointer to [array of int]. Remember that the size is also part of arrays type. So, in our case, arr is an array of [4 element array of int]. So, it decays down to pointer to [4 element array of int].

So you should write

void f(int (*m)[4]) {

}

Or, you can just take an array of array

void f(int m[][4]){
}

Note that only the size of the rightmost column is required in the formal parameters list.

Pointers and Structures and Unions

Now we move on to struct and union. We can have pointers to them too.

struct some_struct {
    int p;
    int q;
}

struct some_struct a;
struct some_struct *pa = &a;

Or if you prefer a typedef

typedef struct some_struct {
    int p;
    int q;
} some_struct;

some_struct a;
some_struct *pa = &a;

An interesting situation occurs when you want to access members of struct using pointer. Suppose you want to access the member p through pa. You might do

int k = *pa.p;

Except, this doesn't do what you expect. The operator . has higher precedence than * so *pa.p is same as *(pa.p). So instead of dereferencing pa and then accessing the member p, you end up accessing the member p and then dereferencing it. But pa doesn't have a member p. So, it gives a compiler error.

Instead, you want to write this

int k = (*pa).p;

Which works the way you want. But writing this is tedious, and turns out that we write this so much that they have a special operator ->

int k = pa -> p;

pa -> p is same as (*pa).p but looks neat and clean.

The case of unions is a little bit involved. Quoting cppreference -

A pointer to a union can be cast to a pointer to each of its members (if a union has bit field members, the pointer to a union can be cast to the pointer to the bit field's underlying type). Likewise, a pointer to any member of a union can be cast to a pointer to the enclosing union.

What it means is that, if you have a pointer to a union, you can cast it to any of its members, and vice versa. Take a look

typedef union some_union {
        int p;
        char q;
    } some_union;

some_union a = {1}; // Initialize a with p = 1
some_union *pa = &a;
printf("%d\n", pa -> p); // Access p through pointer to a

int * pb = (int *) pa; // cast pa to point to p directly
printf("%d\n", *pb);

This prints

1
1

Here, I could cast the pointer to a to an int* and it automatically pointed to the member p. Similarly, if I had cast it to char* it would point to q.

Conversely, if I had a pointer to p, I could cast it to a pointer to some_union and it would point to a

int *pc = &(a.p);
some_union *pd = (some_union *)pc;
a.q = 'a';
printf("%c\n", pd -> q);

This prints a as expected.

Ministry of Pointer Magic

Pointers and Function

It is possible to have pointers to functions too. Remember that the return type, the number of parameters it takes, and the type of each parameter - these 3 are parts of the type of a function. Hence you must provide these during pointer declaration. Also worth noting () has higher precedence than *

int *f(); // a function that returns a pointer to int
int (*f)(); // a pointer to a function that takes no argument and returns an int
int (*f)(int); // a pointer to a function that takes an int and returns an int

A pointer to function can be used just like other pointers -

int f(int a) {
    return a+1;
}

int main()
{
    int (*fp)(int) = &f;
    printf("%d\n", (*fp)(1));
    // printf("%d\n", *fp(1)); Wrong~ Won't cpmpile
    return 0;
}

This prints 2 as you'd expect.

Remember I talked about declaration follows usage? Well, turns out that in the case of pointer to functions, that rule can be ignored. For example, this works

printf("%d\n", (**fp)(1));

And so does this

printf("%d\n", (*********fp)(1));

And weirdly enough, this too

printf("%d\n", fp(1));

So, in the case of functions, not only you can dereference as many times as you want, you can drop the dereferencing altogether and just use the pointer as if it were a function itself. Another one of those C quirks.

Finally, you can get wild with pointers and arrays and function like

char *(*(*foo)[5])(int); // foo is a pointer to array of 5 elements of pointer to a function that takes an int and returns a pointer to char
int *(*foo)(int *, int (*[4])()); // foo is a pointer to function (that takes a pointer to int and a 4 element array of pointer to functions that return int) and returns a pointer to int

You get the idea. Yes, it can get pretty messy, but once you know the syntax, and you have cdecl, you can easily breeze through them (or read my article)

As for how you can use a function pointer. here's an example of a simple calculator

#include <stdio.h>

float add(float a, float b) { return a+b; }
float sub(float a, float b) { return a-b; }
float mul(float a, float b) { return a+b; }
float divide(float a, float b) { return a/b; }


int main()
{
    float (*arr[4])(float, float) = { add, sub, mul, divide };
    int n;
    float a, b;
    printf("Enter two numbers: ");
    scanf("%f%f", &a, &b);
    printf("Enter 1 for addition, 2 for subtraction, 3 for multiplication, 4 for division: ");
    scanf("%d", &n);
    printf("%f", arr[n-1](a, b));

    return 0;
}

We are storing all 4 operations in an array and when the user enters a number, we call the corresponding operation.

Qualified types

Each type in C can be qualified by using qualifiers. In particular we have 3 - const, volatile, and restrict. Here we will look at const and restrict.

Adding const to a type effectively marks it read-only, so that attempting to change the value will result in a compiler error.

const int p = 1;
p = 2; // error: assignment of read-only variable ‘p’

Turns out, int const and const int both are valid. Now if I throw pointers into the party, I get some fun stuff

const int *p;
int * const p;
const int * const p;

Can you guess which one is what?

To untangle this, we will remember some_data_type *p declares p to be a pointer to some_data_type

Hence, const int *p can be thought of as (const int) *p. So that p is a pointer to a const int. It means, whatever p is pointing to is a const int and you cannot change that. However, p itself is not const and can be changed.

const int a = 1;
const int b = 2;
const int *p = &a;

p = &b; // works. You can change p
// *p = 3; error: assignment of read-only location ‘*p’

For the second one compare it with int const p which declares p as a read only int. So, int * const p should declare p as read-only int*. This means the pointer itself is const and you can't change p , but you can change what p is pointing to.

int a = 1, b = 2;
int * const p = &a;

*p = 2; // Works. you can change *p
// p = &b; error: assignment of read-only location ‘p’

And finally, const int * const p declares that both p and *p are read-only. So you can neither change p nor *p.

const int a = 1, b = 2;
const int * const p = &a;
// *p = 2; error: assignment of read-only location ‘*p’
// p = &b; error: assignment of read-only location ‘p’

Now let's look at the restrict keyword. The restrict keyword, when applied to a pointer p, tells the compiler that as long as p is in scope, only p and pointers directly or indirectly derived from it (e. g. p+1 ) will access the thing it's pointing to.

Confused? Let's see an example.

void f(int *p, int *q, int *v) {
    *p += *v;
    *q += *v;
}

Here is the assembly generated after enabling optimization -

mov     eax, DWORD PTR [rdx]
add     DWORD PTR [rdi], eax
mov     eax, DWORD PTR [rdx]
add     DWORD PTR [rsi], eax
ret

The problem in this function is, p, q and v might point to the same location. So that when you do *p += *v, it might happen that *v also gets changed because p and v were pointing to the same location.

This is why *v is first loaded into eax by mov eax, DWORD PTR [rdx]. Then it is added to *p. Again, we have to load *v because at this point, we are not sure if *v has changed or not.

Now if I update the function as follows -

void g(int *restrict p, int *restrict q, int *restrict v) {
    *p += *v;
    *q += *v;
}

the compiler is free to assume that p, q and v all point to different locations, and can load *v only once, and indeed it does

mov     eax, DWORD PTR [rdx]
add     DWORD PTR [rdi], eax
add     DWORD PTR [rsi], eax

Note that it is up to the programmer to guarantee that the pointers do not overlap. In case they do, it is undefined behavior.

You can read more about restricthere.

That's probably enough for one post. To quickly recap, you have learned -

What pointers are.
How to declare and dereference pointers.
Pointer arithmetic.
Pointer comparison.
Pointer to array and array of pointers.
Pointers and arrays are not the same.
Pointer arithmetic and array indexing are equivalent.
Array in function parameter decay to a pointer.
Pointers to a multidimensional array.
Pointers to structures and unions.
Pointer to functions.
Pointer to wild exotic types.
const and restrict with pointers.

Note that most of these hold true in C++ also, although you have minor changes, and some new stuff like smart pointers.

Hopefully, you learned something new in this post. Subscribe to my blog for more.

Replace your Existing Unix Utilities with These Modern Alternatives

Aniket Bhattacharyea — Fri, 30 Jul 2021 17:34:34 +0000

In your day-to-day Unix or Linux usage you use different tools like cd, ls, grep, or find. These are ubiquitous utilities found in every Nix system. However, they were created a long time ago, when computers lacked computational power and speed. These tools were tailored towards systems with very little resources. Nowadays, our systems are far better and our requirements are far bigger. In this article, I will show you some utilities aimed towards providing modern replacements for these useful Unix utilities.

`bat`

bat is a modern replacement for cat written in Rust. Unlike cat, this tool supports syntax highlighting for many programming languages out of the box.

Another interesting feature of bat is native Git integration. If you run bat from a git repository, you will get a "git gutter" indicating modification with respect to the index.

By default, bat automatically pipes its own output into a pager (e. g. less) when the output is bigger than one page. Which means you don't have to manually pipe the output into less.

If you wish to replace cat with bat, you can use the following alias -

alias cat='bat --style header --style rules --style snip --style changes --style header'

`exa`

exa is a modern alternative for ls, also written in Rust. Apart from some minor differences, exa has all the features of ls, along with Git integration and colors.

Using the --git option, you can quickly see the Git status of files inside a Git repo.

You can use the --tree option to get a tree view of the files. Using the --level option, you can specify the depth of the tree.

You can use the --icons option to display little icons next to the filenames, provided your font contains those icons. You can install any Nerd Font and you should be good to go.

`dust`

dust is an alternative for du, and it should not be surprising that it is written in Rust! When you run dust, it shows a nice tree structure of files and folders along with a visualization of sizes.

`duf`

duf is a replacement for the df utility. Guess which language it is written in? Nope, not Rust. It's written in Go.

duf makes the output easy to understand and visualize. It has color highlights and percentage bars so that you can easily understand your disk usage. Also, it separates local devices, network devices, and special devices in separate regions.

You can use duf --all to list all devices including pseudo, duplicate and inaccessible devices.

You can also use duf --json to output a convenient JSON file.

`fd`

fd is an alternative for the find utility. And we're back again to the Rust world!

When you run fd command with a search pattern, it will search the current directory for the pattern and show you the file list.

You can also use regular expression to refine your search.

You can search for a specific extension by using the -e flag. You can combine this with the search pattern.

Just like find, you can run a command on every found file using the -X flag.

`ripgrep`

ripgrep is a super fast grep alternative written in Rust. Apart from being super fast, it also respects your .gitignore.

ripgrep is invoked through the rg command. The basic usage is similar to grep. You provide a pattern and a file to find the pattern in. rg by default also shows the line numbers and highlights the search term.

rg also supports regular expressions.

If you do not specify a file name, rg will perform a recursive search. Similar to grep -r.

rg respects your .gitignore. Which means if a file is matched in .gitignore, it will not be searched. You can read more about how to use this feature in the manual.

`tldr`

How many times have you forgot how a command works, and opened the man pages only to get buried under tons and tons of documentation, when you only wanted some examples? tldr is not an exact replacement for man pages, but it is a community effort to simplify the manual pages. Rather than throwing an ocean of information about you, tldr lists examples and small details, enough to get you started.

`procs`

Yet another tool written in Rust. procs is a modern alternative for ps. When you run procs, it shows you a list of running processes in a nicely themed output. The output is automatically paged.

If you run procs followed by the name of a process, procs will search for that process, similar to running ps aux | grep process.

procs can also show other information which are not available to ps, like TCP/UDP port, Read/Write throughput, or Docker container name. You can read more about them in the procs manual.

`zoxide`

zoxide is a fast replacement for the cd command. It keeps track of the directories you visit and can quickly take you to the directory you want to go.

You can use zoxide just like the regular cd command. For example,

z foo/bar/baz

zoxide keeps a track of the directories you visit, and you can use fuzzy finding to quickly visit a directory you have visited before.

z baz # Takes you the highest ranking directory matching baz

zoxide also comes with various integrations with many different tools. Check them out from their manual.

I hope you could find your next favourite command line utility from this post :). If you liked this article, do not forget to share and subscribe to my blog for more such articles.

Help needed in figuring out Rails association

Aniket Bhattacharyea — Sat, 06 Jun 2020 08:40:47 +0000

I have two models - User and Network. In my case, each User can have many Network and each Network can have many User and belongs to one User (the one who created).

For example, let's say there is user1 with two networks N1 and N2. The network N1 has user2 and the network N2 has user3.

What I want to achieve is the creator field of N1 and N2 will give me user1 and the users field of N1 will give me [user2] and that of N2 will give me [user3]

So far, it's ok. I can have the creator field with foreign_key, and I can use a has_many through relation to figure out which networks contain which users and which users belong to which networks.

But in that case, is there a way to quickly tell if there is a relation between two users or not?

For example something like user2.follows? user1 will return true since user2 belongs to a network of user1. I can iterate through all the networks created by user1 and check if user2 belongs to it, but is there a better way?

Safety App - a Project I made as a Student

Aniket Bhattacharyea — Fri, 22 May 2020 09:21:09 +0000

As you might know, I am currently a student. As a mathematics undergraduate in the final year, Covid 19 has been a major setback. Recently, I found out about the yearbook initiative by Github Education and wanted to share a project of mine as a student.

It's a little difficult for me to consistently work on a project. Apart from studying and teaching students I also work as a part time web developer in DataSutram. Anyway this one had a personal interest.

Last year one of my friends told me about a kidnapping in her area and it scared me to my core. I thought if I could do anything to help it would be nice. So I made the Safety App

What it does

It's a pretty simple application. It's main feature is that it lets you select your trusty contacts and makes it easier to contact them during emergency.

You can choose as many contacts as you want.

The app shows two persistent notifications

The first one has 3 buttons. The first button is for making calls. If you click on it you will be shown a dialog with a list of your trusty contacts.

If you click any of them, it will call the contact. The same with 2nd button except it launches the SMS app where you can send them an SMS.

The third button is the most important one - SOS. When you press it, it will send an SOS to every trusted contact with your location.

Observe that in every screenshot the first contact is called "Super Trusty Contact". It's because it is a special contact. How?

These notifications are visible in the lockscreen too. When your screen is locked, there is no way to show you which contact to pick. There it picks the first contact. That's why it's super trusty. Although, the SOS os always sent to every contact.

As for the 2nd notification, it's like the SOS but it lets you capture an audio and uploads it to the cloud and sends a link to your contacts.

There is also a map in the app which shows you locations of nearby police stations, hospitals etc.

If you click one of them, you can get at a glance a few infos and also a basic route.

How I made it

The app is written in Kotlin and open sourced here. Code wise this is not the best thing I have made. There are repetition everywhere, redundant codes and buggy stuff, but I wrote it in a hurry.

Things to do

Currently there are a few bugs. The notifications don't show up in the lockscreen for some phones. The notifications might disappear. Sometimes the app also crashes and sometimes the location cannot be fetched.

I'm working on those issues and it's really difficult managing time for everything. Hopefully I'll get around to fixing them soon.

Final words

The app is free forever and ad-free. This is an app that is meant to help people and I do not want to profit off ot. But still, the cloud is costly and I'm just a student managing my studies. If you find the app useful, and want to support development, you can donate from the app. You can also Paypal me at aniketmail669@gmail.com

P. S. Our state just faced the fiercest super cyclone since 1737 and we're in debris. It's been 48 hours and we still have no electricity and we've run out of water. So please #PrayForBengal and let's hope we can turn around.

My Journey With Linux (September 2015 to present)

Aniket Bhattacharyea — Thu, 25 Apr 2019 15:17:23 +0000

(This is a repost from my blog which I thought would be a good place to post here)

Linux — the first thing that comes to mind when you hear this word is the image of a nerdy, bearded person, running commands after commands like a blaze.

I also had this image, and honestly, I used to be scared of Linux. People around me had (and still have) vague ideas about Linux. Nobody knew what it is, and told me not to try it.

So, I tried it. And fell in love with it.

This story captures my journey with Linux, starting from 2015, When I got my first computer, to the present time, and to the future. You will see a noob heading towards achieving perfection in this story —

P.S: After trying Linux, I am really a nerdy, bearded guy, typing commands after commands (not like a blaze).

Reasons for trying it out

I wanted to make a custom ROM for my phone in 2015. On XDA, all the guides used Linux. I was a Windows lover back then (yes, I was) and had zero experience with Linux. Then I found out about Cygwin Linux emulator. But the XDA threads said it’s buggy, unstable and it installs about 1gb of software. I didn’t have unlimited internet back then, and Ubuntu was almost of the same size. So I thought if both of them are the same size, why not download the stable one? After all, I’m all about learning.

First try — Puppy Linux

I decided to go for Ubuntu (Sep 2015), but noticed that I didn’t have enough data. So, searching for something light, I came across Puppy Linux (250mb) and decided to try it.

The installation of Puppy had instructions about “full” and “frugal” installation, which were beyond my understandings at that moment. Nevertheless, booted up the live CD, and in order to create a partition, opened GParted. I knew nothing about filesystems and formatted the whole drive as ext4. The result? My windows won’t boot up. Tried to reinstall Windows, but the installation disk would not list any partition. Somehow I managed to format the drives as NTFS and installed Windows 7.

What I learned —

Never try to mess with your partitions without having a vast idea.

2nd try- Ubuntu

Oct 2015, decided to go again. This time, Ubuntu Vivid Vervet 15.04

This time, everything went fine and set up a working installation. It was a bit uncomfortable first, especially the buttons being on the left side of the toolbar. But I grew accustomed with time. Still, I preferred Windows. Some things (like installing apps via CLI) were new to me, and not having enough knowledge resulted in a lot of things not working. But I didn’t lose patience and kept learning.

What I learned —

Basics of Linux, simple terminal commands.

3rd try- Kali Linux

Feb 2016, replaced Ubuntu with Kali Linux 2016.1 rolling. This is the distro which made me fall in love with Linux. Meanwhile, windows started showing some bugs. So I started spending more and more time with Linux. Using Kali Linux, I even built my Linux from scratch. Also, the troubleshooting in kali gave me a deep knowledge about Linux.

What I learned —

More commands and concepts of Linux.

4th try — Linux from Scratch

Using Kali, I made a Linux from Scratch and named it Papiya Linux after my mom. Although it never went public, it gave me a HUGE knowledge.

What I learned —

Concepts of Linux — how packages work, how two softwares communicate with each other and the kernel, different states of processes.
More commands.
Use of sed and grep and find.
Writing complex bash scripts using if, while, for, head, tee, cut etc.
Compiling softwares from source.
Analyze the output of make and troubleshoot.
Use of aclocal, configue, autoreconf and make.
Vim.

Arch Linux

Since August last year, I have been using Arch as my main OS. Windows is still there. And an empty partition where I try out new OS’s.

I really love Arch, because of its super fast pacman, a huge repository, and an awesome Wiki.

However, October last year, I ran into a problem. I converted my ext4 installation into btrfs. For those who don’t know, btrfs offers a tool to convert from ext4 to btrfs without losing data, and it also creates a backup image in case you want to revert.

After trying btrfs for a week, I felt no need of reverting, so deleted the backup image. Wrong choice!!

For some reason I opened Windows, and being Windows, it couldn’t recognize my btrfs partition, and corrupted it. And Arch won’t boot.

I saved it by using the tools btrfs offers (btrfs — check-extent-tree and btrfs — init-csum), however a few days later, Windows corrupted it again, this time drastically.

All my executables were corrupted, and it was beyond repair, and my only choice was to reinstall. But I would lose all the data.

My home partition was on the same drive as the root, and if I reinstalled, I would lose everything. But since “reinstall and start from scratch” is so Windows style, I figured out a way.

I had to save my home directory.

So, I booted a live cd, mounted another partition, and rsynced my home directory in this drive. Now I could reinstall the OS. But what about my apps those were installed?

Well, it’s Linux.

I found out pacman stores the data about packages in /var/lib/pacman/local. Each package gets its own directory in this format - package _ name — version — revision So, I could do this -

for i in /mnt/var/lib/pacman/local
do
echo $i >> list
done

This would create a file called “list” which would contain the list of packages to install, but it would contain the version numbers too, which I don’t want. So, I used Bash’s string splitting to split the string from the second last hyphen. This would get only the package name -

for i in /mnt/var/lib/pacman/local
do
i = ${i%- * }
i = ${i% — *}
echo $i >> list
done

Could this be done in any other way? Tell me in the comments.

This created the desired list. The rest was easy, booted the Arch live CD, fed this file to pacman, and pointed pacman to the installation path. After everything was installed, created the user, and restored my home directory, BUT this time to a separate partition, so in case anything goes wrong with the root partition, I can save my home directory.

What I learned — 1. Never delete backups. 2. Never trust Windows. 3. Always keep your home directory on a separate partition. 4. Use your goddamn brain. 5. Fix your own shit yourself.

In April this year, I screwed up once again. I decided to ditch Windows and Fedora completely and make Arch the only OS. Also, I wanted to clean up my HDD, which was one hell of a mess of partitions.

So, I rsynced my root and home partition to another NTFS partition and by the time I realised my mistake, it was too late. Yes, you can guess what happened. As I backed up to NTFS, I lost all the permissions. All the files were set to rwxrwxrwx.

After banging my head on the desk for a few hours, I remembered pacman can check for file integrity. So, it must store the data somewhere. After looking at the database (/var/lib/pacman/local/) I found out pacman stores the metadata in a mtree file under package directories. These mtree files are nothing but a gzipped data file.

I tried to restore the permissions with BSD mtree but it gave some errors because the format was not recognised. So, I wrote my own parser in Bash (sorry lost the code). It parsed the permission data from the mtree files, and applied them. There were 5 or 6 edge cases where my coding magic did not work, but I could fix them manually.

What I learned —

Backups are important, and be sure where you are backing up.

January 2018

It’s only been 1 month of 2018, but the Linuxer (is that even a word?) inside me is urging for something better. So I decided to “upgrade” my installation.

First thing I noticed, I was still using BIOS and MBR, which was, unknowing to me, chosen by the one who installed Windows on my laptop when I bought it.

My first target was to convert it to EFI and GPT.

The first part was easy —

Create an ESP partition.
Mount it to /boot/efi
Install grub-efi.
Update grub files.

The last two parts I had done before, and there was no way I could fuck that up and I did.

After 1 hour of grub not being recognized, I realised I had to copy grub64.efi to ESP/EFI/Boot/BOOTx64.efi.

After I did so, grub was recognized, but it didn’t boot.

After 2 hours of grub not finding the kernel and initrd files, I found out it was due to an issue with incorrect mount path.

After successfully configuring grub, I was satisfied and confident. So I nuked grub, and installed Refind, and got it running in the first try :)

The next part was easier, I just used gdisk to convert MBR to GPT and it worked flawlessly.

I also made zsh my default shell. After years of loving Bash, I finally moved on to new horizons.

What I learned —

Sometimes changes are refreshing.

Rest of 2018

I did not do much of a change in 2018. I got an internship and later a work from home job, so inevitably I resisted to breaking changes. There were few hiccups along the way, but not too challenging.

But it doesn’t mean I learned nothing new. I worked as a System administrator and backend developer in my work and had to use Linux extensively. In particular, I learned -

Docker and Gitlab CI/CD
Server deployment and Apache and Nginx configuration.

January 2019

In December 2018, however, I built a new PC, which meant I had a place to start from scratch. Although I built it in December, there were some issues with the motherboard so I had to wait until January to get it working.

This time, unlike the previous ones, I knew what I wanted, and I knew how to do it. I set up an LVM with two LVs — one for root and one for home and installed Arch Linux.

The installation was not so smooth because my WiFi adapter needs a driver that doesn’t ship with the kernel by default. Thankfully it’s available in AUR.

I also switched to Fish shell. It’s not POSIX compliant so few of my favourite features don’t work (&& and || for example, although they added them to fish a few weeks after I started using it. What a time to be alive), but change is a good thing.

I also have only Plasma on the desktop and not every single Window manager in existence like the laptop. I also have a strict no-experimentation rule with the work machine.

One good thing I did was customizing Vim. I took inspiration from here and changed a few things — replaced Pathogen with Vundle, changed some old plugins to better ones, added a few more, changed some configurations, and replaced Vim with Neovim. As an end result, my Vim is nowhere short of an IDE. Epic Linux guy moment!

April 2019

I recently came to know about NixOS. It has a unique approach to package management. It’s kinda like Yast, but better. The idea is, you write all your packages and configuration in a central location and the OS will build itself according to it. Upgrades are atomic, you can rollback any time. And packages are sandboxed so you can install multiple versions of the same package without conflict, or install packages without worrying about dependencies.

So I said bye to the Arch on my laptop and installed NixOS. So far, it’s been a little unconventional to work with, but hopefully I’ll adapt to it soon.

Conclusion

People will say, “Linux is shitty.”, “it does not have many softwares,” “I used to have this on Windows and it’s not on Linux.” etc. Believe me, I felt the same for the first two months, but I didn’t lose patience, cause I’m switching OS, so I must expect things not to be the same. I’ve been to the dark sides of Linux, and I have seen what it can do.

I have leaened a lot of things. I have gained a lot of experience. It was hard to learn all by myself without any guide, but if I can do it, anyone can.

I will update this story with new milestones.