DEV Community: Aniket Bhattacharyea

How to Be the Best Tutorial Writer in the Room

Aniket Bhattacharyea — Wed, 26 Aug 2026 12:34:57 +0000

There's a special kind of pain reserved for people who follow a tutorial at 11 PM and hit a wall on step 4 because the author renamed a variable between step 3 and step 5 and never told you. You stare at your terminal. The error makes no sense. You check the code four times. Eventually you realize the tutorial was never run, start to finish, by a human being — it was assembled from memory, vibes, and whatever the author thought they did six months ago.

I don't want to be that person, and after enough tutorials spanning across clients like Docker, Auth0, JetBrains, and others, I've settled on a short list of things that actually separate a tutorial that works from one that just looks like it does. None of this is exotic. It's mostly discipline, applied at the right moments, and a healthy suspicion of your own memory.

I'm not going to talk about the same old boring advices like "Improve your English, use your own language." I myself am not a native English speaker, and I write very simple sentences -- no flowery language, no complicated prose -- and I can tell you that no client has ever questioned me about that. I'm going to give you some real advice, battle tested with real clients.

Disclaimer: All of the points below are my own advice, learned from my experience with Draft.dev. These aren't absolute gospels, and you shouldn't take them as such.

1. Clearly Define the Article Requirement

Before you write a single sentence, know what the article is actually supposed to deliver. Not the topic — the shape. Is this a 500-word "here's a neat trick" post, or a 3,000-word soup-to-nuts build? Does it stand alone, or does it assume the reader already has your last three articles' worth of setup done? Is the deliverable a working demo app, or is the demo just scaffolding to explain one specific concept?

I cannot stress enough the advantages of creating an outline before you start writing. I prefer to collect all the information I can from my clients, including details about their company, their product, and the topic, and create an outline with it. An outline gives you the basic shape of the article and tells you what to do, and what not to do.

You can download a copy of the "content plan" template I use with my clients here.

2. Create a Compelling Scenario

Once you know the requirement and before you touch the audience question, decide what the demo app is actually about. This is where a lot of otherwise-solid tutorials go flat, because the author reaches for the most generic possible container for the feature they're demonstrating.

Say you're writing a tutorial about authentication and authorization. The lazy version of the prompt to yourself is "let's create a basic app and add authn and authz." Technically accurate, and it produces exactly what it promises: a to-do list or a "hello, dashboard" page with a login screen bolted onto it, and a role check somewhere that simply prints your roles on an HTML page. Nobody remembers that tutorial a week later, because there was nothing to remember.

Compare that to: "let's build a CMS where anyone can sign up, write and publish articles, but can't delete someone else's article." Same underlying feature -- authn and authz -- but now it's a scenario, not a checklist item, and the scenario does several things the generic version can't:

It forces you to define real roles before you write any code, because "someone else's article" only means something once you've decided who owns what. That's authorization design, not authorization theater.
It gives you a built-in negative test case for free. "User B tries to delete User A's article and gets blocked" is a genuinely satisfying moment to demonstrate -- readers get to see the authorization actually stop something, instead of trusting your word that the middleware is wired up correctly. A generic "protected route" demo never gets to prove a negative like that.
It reads well in a title and in a search result. "How to Build a CMS with Role-Based Permissions" gets clicked. "How to Add Authn and Authz to a Basic App" reads like a boring text.
It gives your screenshots something to be of. A login form looks like every other login form ever screenshotted. An article list with a greyed-out delete button next to someone else's post is an image that actually explains the feature at a glance.

A compelling scenario is really the requirement and the audience decisions from the last two points, made concrete enough to build. If your scenario is interesting enough, half of your outline writes itself, because the scenario itself implies the steps: sign-up, write a post, publish it, try to break it as someone else. Boring scenarios don't do that work for you -- you end up having to invent steps to pad the tutorial out, and padding is always the first thing a reader notices.

Note: A compelling scenario doesn't have to be elaborate. It just has to be specific enough that a stranger, reading only the title, already has a rough guess of what the finished thing does. Don't get carried away and try to make it too complex.

3. Clearly Define the Audience

This ties to the previous point as this is part of the outline for me, but it's so important that this requires its own paragraph. This is the single biggest lever on how much detail you show, and it's the one people skip because they think they already know. "Developers" is not an audience. "Someone who's shipped a REST API before but has never touched OAuth" is an audience.

Audience determines everything downstream: whether you explain what a JWT is or just link to a reference, whether you spell out npm install or assume it, whether you show the full error message or just say "if you see an auth error, check your redirect URI." Undershoot the audience and you lose beginners on page one. Overshoot it and your expert reader skims past three paragraphs of npm install ceremony looking for the one paragraph that matters, and maybe doesn't find your article again next time.

I write a one-line audience note to myself before drafting — something like "assumes React familiarity, zero assumption of Next.js server actions" — and I keep it visible while writing. Every time I'm about to explain (or skip explaining) something, I check it against that line instead of against my own head, because my own head thinks everything is obvious by the third read-through.

Here's a concrete example of how audience shapes the article details for me. Imagine I am teaching how to create a Next.js app. If my audience is a beginner who has zero to minimal Next.js experience, I'll start with:

Run the following command to create a Next.js app:

npx create-next-app@latest my-app --yes

Now move into the directory by running "cd my-app" and start the dev server by running "npm run dev"

But if my audience is intermediate or expert in Next.js, I'll write:

Create a Next.js app and start it.

Note: There is one situation where I'll spell out the details irrespective of the audience. That is, if I'm doing something that is not the default. For example, I'm using a different version of a tool, or passing a non-default option to the command.

4. Build the App First, to Know It Works

This should not need saying, and yet. Before you write a word of prose, build the actual thing, end to end, on your machine, from a clean slate if you can manage it. Not "I did something like this six months ago and it's basically the same." Build it now with the versions of the tools that exist.

The reason this matters isn't pride — it's that software drifts under you while you're not looking. An SDK bumps a major version and renames a constructor argument. A framework moves from pages to app router. A CLI flag gets deprecated with a warning nobody reads. If your mental model of "how this works" is even a few months stale, you will confidently write down something that used to be true.

This happened to me on my own side project, actually — not an article, but close enough to sting the same way. I stubbed an external client in my tests, the tests passed, and I moved on trusting that green checkmark. Then I ran the app for real and discovered that the library had changed its constructor from keyword arguments to positional ones between the version I remembered and the installed version. My stub accepted anything, so nothing caught it. The lesson transfers directly to writing: a test (or an article) that was never run against the real thing isn't verification; it's a nice story you're telling yourself.

This is also useful when you're writing about a client's product. Many clients -- typically young startups -- don't pay as much attention to their documentation as they do to their marketing. Often, their docs will say "do X to get Y," but when you actually try it, you'll discover it doesn't work. Either the feature doesn't exist, but the Sales team got excited and claimed boldly that it's available, or that the docs were hallucinated by an AI, or maybe it worked at some point, but something changed, and nobody updated the docs.

That's why build it first. Confirm it works. Then start writing about it. As you build the app, try to develop a mental model of the steps you will show in the article, in what order. Building the app will tell you everything you need to do to get it working. You can write it down or memorize it. Either way, you now have a solid foundation of what works and what doesn't.

5. Build the App Once More as You Write

Here's the part people skip because they just did step 4, so surely they remember what happened. You don't, not precisely enough. The gap between "I built this, and it worked" and "I wrote down, in order, the exact commands and code that make it work" is wider than it feels.

As you write each step, actually perform that step again, right then, and paste in what genuinely happened — not what you remember happening. This catches the stuff that ruins tutorials: the config value you tweaked halfway through and forgot to write down, the folder you created out of order, the environment variable you set in one terminal tab and never mentioned. Writing and rebuilding in lockstep turns your article into a transcript of something real rather than a summary of something remembered.

Building the app as you write the article will also let you capture screenshots and outputs immediately, making the article feel more alive. More on this later.

6. Build the App One More Time as You Go Through the Final Copy

By the time you're proofreading, you're reading your own writing, and your own writing is exactly the thing you're least equipped to catch errors in — you know what you meant, so your eyes helpfully autocorrect what you wrote. A missing cd into the right directory, a code block that's missing the import you added at the last minute, a step that got reordered when you moved a paragraph for flow and never noticed the code above it now depends on something that hasn't happened yet.

The fix is unglamorous: go through the final copy one more time, but instead of just reading it, execute it, literally, in a fresh terminal, following your own instructions exactly as written rather than as intended. Not "run something like this" — copy the actual commands out of your own article and run those. This is the pass that catches the copy-paste artifact from an earlier draft, the snippet that references a variable you renamed three sections ago, the step you accidentally deleted while editing for length.

Three build passes sound like a lot until you consider that each one is catching a completely different class of mistake: the first confirms the thing is possible, the second confirms your narration of it is accurate, the third confirms your edited, final narration is still accurate after you've been moving paragraphs around for an hour.

The next few tips are "cosmetic." They don't improve the correctness of your article, but they make it better by a huge margin.

7. Show Full File Paths in Code Snippets

A code block that starts with export default function Page() { and nothing else creates more questions than it answers. Where does this go? Is it a new file? Does it replace something? Which folder, at what level, relative to what?

Show the actual path, every time, even when it feels repetitive: frontend/src/app/api/quote/route.ts, not route.ts. Especially in a monorepo, or anything with more than one plausible src/, guessing the path is exactly the kind of low-value puzzle that makes a reader feel dumb for a reason that has nothing to do with their skill and everything to do with your laziness. Full paths cost you only a few extra words per snippet and save the reader a headache and a moment of quiet resentment toward you specifically.

Here you might argue that if the audience is an expert, surely they can figure out where to put the code if I say "the quote route" instead of frontend/src/app/api/quote/route.ts, and that's a valid argument. I prefer to reduce confusion as much as possible, so I almost always mention the full path, regardless of the audience. Better safe than sorry.

8. Clearly Indicate Where to Put the Code

Adjacent to the path problem, but distinct: a snippet with a correct path can still land in the wrong place inside that file. "Add this" is not an instruction. "Add this snippet at the top of frontend/src/lib/strapi.ts, right after the existing imports" is. "Replace the return statement at the bottom of the handler function with the following" is. Say whether it's a new file, an insertion, or a replacement, and say exactly where the insertion point is relative to something the reader can already see in their own editor.

This matters more, not less, as snippets get shorter. A ten-line code block dropped in the middle of a paragraph with no context is the single most common way I've seen a technically correct tutorial become a frustrating one — not because the code was wrong, but because the reader had to guess what to do with it and guessed wrong.

Don't refer to code by line number, like "Paste this code after line 15." Even if a reader has been following your article and has been copy pasting the exact codes from your article, they may end up having different line numbers. The most common reason is IDE auto-formatting that automatically formats the code as they paste. The reader themselves may decide to format the code in a different way. Always indicate lines via some sort of marker, like "Paste this after the closing tag."

9. Provide Screenshots, Outputs and a Repo

Three different deliverables, all necessary in my opinion.

The screenshot has two jobs. One, it is proof, aimed at the reader following along: "here's what it should look like when you get this right," so they can check their own result against something concrete instead of just trusting that the code compiled. It's also aimed at people skimming to decide whether the article is worth their time at all — a screenshot of a real, working thing does more convincing in half a second than three paragraphs of description.

It's second purpose is to give the reader a visual cue. A screenshot of the web page with the button circled in red is easier and faster to understand than "Click the small + button in the top right corner of the page."

Note: Two things you must never forget with screenshots: Point out the interesting things (for example, circle the button you want the reader to click, or put an arrow next to it) and include an alt text and caption.

The code outputs have a similar responsibility as the screenshots. They provide a visual indicator. If the user gets the same output as you, they will know they are on the right path. To switch things up a bit (or to save yourself for pasting a huge output), you can also indicate what to look for. For example, "If the status command shows Running, you're good to go.

The repo is the escape hatch, aimed at the reader who's stuck. Tutorials are read out of order, skimmed, half-followed, interrupted by lunch. A linked repo at the final commit state means "I did something slightly wrong three steps back" doesn't have to become "I give up" — it becomes "let me diff my folder against theirs." Also, a repo is a better proof of "It works" than a screenshot. Someone can simply check out the repo and test whether the app works or not before deciding to read your article. I link a repo on effectively everything now, and it's the single piece of feedback I get thanked for most often, more than any clever explanation in the prose itself.

I link the repo twice. The first link is before starting the tutorial section, saying something like "All the code I am using in this article can be found in this repo." This gives the reader the escape hatch mentioned earlier before they actually start investing into the tutorial. The second link is after the tutorial is over, with something like "You can check out the full app in this repo." This works as a "tie everything together" moment. If they didn't check out the repo earlier, they can do so now, and compare their app with mine.

A couple of principles I follow when creating a repo for my tutorials:

The repo should be the exact same as what my article produces. I basically use the repo I got from following step 6. This makes sure someone who is reading the article gets the exact same app as someone who simply checked out the repo. I don't do any "final touches" or improvements over what the article has. If I must, I make sure it's not an extensive functionality change. For example, I used basic CSS in the article, but that looks ugly, so I added some CSS styles in the final app. This is ok. But using SQLite in the article because it's easy, but changing it to PostGreSQL in the repo is too big of a change. Not cool.
Sometimes I may provide a starter version of an app. In case the initial setup is too long, I provide a small prebuilt app that I want the reader to use as a starting point for the article. In that case, I provide the starter version and the final version in different branches of the same repo. Starter version in starter and final version in main, or starter version in main and final version in final -- choose whatever suits you.

10. Provide a List of Prerequisites

How many times have you started reading a tutorial and halfway through you realized, "Looks like I need an AWS account for this. No one made that clear!" You don't want to be the person who leaves their readers in the dark about what they need for the tutorial. That's why I add a prerequisites section before the tutorial actually starts. There, I list:

The tools that are needed, e. g. Docker, Node.js
The versions of the tools, where to install them, and which versions I used.
If any third-party tools or services are needed, and where to sign up for them.
If the tools behave sufficiently differently based on OS.

Here's one example prerequisite section:

To follow along with this tutorial, you will need:

* An Auth0 account. You can sign up for free [here](link-to-auth0-registration).
* The latest version of Node.js. This article uses version 22.0.1. You can download Node from [here](link-to-node-website).

Be the Tutorial Nobody Has to Debug

None of the ten points above are secret techniques picked up from some technical writing seminar. Every one of them is really the same instinct wearing a different hat: don't trust what you think you know, trust what actually happened five minutes ago on your own machine. Every "vibes" tutorial I've ever gotten burned by skipped some of these -- usually not out of laziness, but because it felt done already, and the deadline was in three hours.

That's the trap, and it's the same trap every time. A tutorial reads as finished to its author long before it's finished for the reader, because the author already knows what everything means. The reader doesn't. Every point above is just a way of closing that gap -- one more rebuild, one more real file path, one more screenshot, one more line telling them what account to go create before they get 60% of the way in and hit a wall you knew was coming.

I've written these for clients and the ones that got read, bookmarked, and pasted into someone's internal wiki were never the ones with the cleverest explanation of why something works. They were the ones that just worked, on the first try, for a total stranger, with no help from me sitting next to them. That's the whole job. Everything else is decoration on top of that one requirement.

So if you want to be the best tutorial writer in the room, here's the short version: be the one whose tutorial nobody has to debug.

Building a Privacy-Focused Social Media: What It Taught Me

Aniket Bhattacharyea — Fri, 07 Aug 2026 08:43:10 +0000

I've been working on a side project called Vidha for the past few months. It's a social platform with a somewhat unusual premise: instead of choosing between "public" and "private" like every other platform, you control exactly who sees what about you, and it's not just "show my profile picture to my friends and hide it from the public." You can show different versions of every piece of information you enter in Vidha. You can show a formal picture in suits to your office colleagues, the picture you took on your vacation to your close friends, and the picture with your fiancée to your family — all at the same time. Each attribute is scoped to an audience you define.

I want to be upfront: this is purely a personal educational project. There's no company behind it, no funding, no roadmap I'm pitching to anyone. I built it to learn. Specifically, I wanted to understand what actually goes into building a social platform — not the surface-level stuff, but the data model decisions that haunt you at 2 am three weeks in.

This article is about the things that surprised me, the decisions I made and would change, and the problems that turned out to be much harder than they looked.

Tech Stack

Before diving in, here's what I built this with:

Layer	Choice
Framework	Rails 8.1 with Ruby 3.4.9
Database	PostgreSQL
Frontend	Hotwire (Turbo + Stimulus), Tailwind CSS v4
Auth	Devise (with `:confirmable`)
Activity Feeds	GetStream.io (`stream-ruby` v6)
Background Jobs	Solid Queue
Rich Text	ActionText
Deployment	Railway
Dev Environment	Nix devenv

I deliberately chose a "boring" stack. I'm a big fan of Rails because of how robust it is, and how easy it is to get started. The hard problem here is the domain — the visibility system, the feed logic, the moderation — not the infrastructure. Rails is good at getting out of the way, and that's what I needed.

The Core Idea: Audiences, Not Privacy Modes

The central concept in Vidha is groups. Every user has named groups — "Public", "Followers", "Close Friends", whatever they want. Every profile attribute (display name, bio, location, profile picture) is associated with a group rather than directly with the profile. When someone views your profile, the app figures out which group they belong to and shows only the attributes you've configured for that group.

The app only requires your email and a username to register. You're free to define your own attributes, such as Location, Job, etc., and assign a type, such as String, Image, Number, or URL.

Once you define a new attribute, you can assign different values to it for different groups.

The visibility resolution logic looks like this:

def visible_attributes_for(viewer)
  group = group_for_viewer(viewer)
  return {} unless group

  attribute_definitions
    .joins(:attribute_values)
    .where(attribute_values: { group_id: group.id })
    .pluck("attribute_definitions.name", "attribute_values.value")
    .to_h
end

And the group resolution itself:

def group_for_viewer(viewer)
  public_group = groups.find_by(is_public: true)
  return public_group if viewer.nil?

  membership = GroupMembership.find_by(member_id: viewer.id, owner_id: id)
  membership ? membership.group : public_group
end

Three cases: an unauthenticated visitor gets the public group, an authenticated user with a membership gets their group, and an authenticated user with no membership also gets the public group. The fallback to public means your public attributes are always visible to logged-in users who don't follow you. That's a deliberate design decision — if you've put something in your public group, you want strangers to see it.

There are a few "special" attributes (for now, only Display name and Profile picture) that the app uses automatically. Again, you're free to skip them, in which case you get a placeholder value. If you keep your display name undefined, it'll show up as "Anonymous". If you keep your profile picture set to undefined, it'll show a placeholder image.

Conceptually, this is clean. In practice, every new feature affecting profiles had to thread through the same logic, which meant many opportunities to get it subtly wrong. There are many edge cases. For example, you don't have to define the value of an attribute for every group. In that case, it falls back to the public group.

You can then attach groups to posts, and only members of those groups will see the post.

Posts and Comments Are Tricky

Oh, did I mention that posts support full rich-text, including image attachments? And so do comments. You can also mention a user by typing @, and you can reply to a comment. All of that brings new problems.

ActionText looks simple until you actually deploy it. The first surprise was CORS. ActionText supports direct uploads — the browser uploads images straight to your storage backend (in my case, an S3-compatible bucket on Railway), bypassing Rails entirely. That means your S3 bucket needs CORS headers that allow PUT requests from your app's origin; otherwise, the upload fails in production while working perfectly in development with local disk storage. I spent an embarrassingly long time trying to set CORS policies to the bucket from Railway's web dashboard, but it turns out that you need to do that via the S3 CLI. The dashboard lacks the feature.

The second surprise was unattached blobs. When a user picks an image in the editor, Active Storage creates and uploads the blob immediately — before the form is submitted. If they close the tab, navigate away, or just change their mind, that blob sits in your storage bucket forever, attached to nothing. The Rails guide shows how you can purge this using a custom Rake task, but it's up to you to perform this regularly. However, there might be an interesting edge case where your cleanup job runs while someone is in the middle of writing a post or comment and it deletes the files they had uploaded. I don't have a solution for this yet.

The third was mentions. ActionText gives you rich HTML, but @username detection has to be layered on top manually. I scan the post body's plain text for the pattern, batch-look up real users, and write GetStream notifications:

def self.notify_mentions(body, actor, post, comment_id: nil)
  text      = body.try(:to_plain_text) || body.to_s
  usernames = text.scan(MENTION_PATTERN).flatten.uniq
  return if usernames.empty?

  User.where(username: usernames).where.not(id: actor.id).each do |mentioned|
    object = comment_id ? "comment:#{comment_id}" : "post:#{post.id}"
    add_to_feed(mentioned.id, {
      actor:      "user:#{actor.id}",
      verb:       "mention",
      foreign_id: "mention:#{object}:user:#{mentioned.id}",
      post_slug:  post.slug,
      post_title: post.title
    })
  end
end

Rendering mentions as links in the stored HTML is a separate problem. ActionText's stored HTML is a sanitized fragment, so I wrote a helper that uses Nokogiri to walk the text nodes, split on the @username pattern, and replace matches with anchor tags — being careful to collect all text nodes before modifying the tree, because mutating the DOM mid-traversal skips nodes:

text_nodes = []
doc.traverse { |n| text_nodes << n if n.text? && n.content.match?(MENTION_SPLIT) }

text_nodes.each do |node|
  parts = node.content.split(MENTION_SPLIT)
  html  = parts.map do |part|
    m = part.match(MENTION_MATCH)
    m && existing.include?(m[1]) ?
      %(<a href="/users/#{CGI.escapeHTML(m[1])}">@#{CGI.escapeHTML(m[1])}</a>) :
      CGI.escapeHTML(part)
  end.join
  node.replace(Nokogiri::HTML::DocumentFragment.parse(html))
end

The Data Model Rabbit Hole

I spent a genuinely embarrassing amount of time on the data model before writing a single controller. Every entity that seemed simple on day one kept revealing a layer of hidden complexity. The biggest example: GroupMembership. My first instinct was to allow a follower to be in multiple groups simultaneously. You're my colleague and my friend — why can't you be in both the "Colleagues" and "Friends" groups?

The answer is: because then I don't know which group's attributes to show you. The visibility resolution breaks the moment a viewer can belong to more than one group. So I added a hard constraint: a follower belongs to exactly one group per owner. That one constraint simplified everything downstream. But it also meant that moving someone to a new group is a replace operation, not an add — and I had to make sure the feed subscriptions stayed in sync whenever that happened.

Another fun one: every new user automatically gets a "Public" group and a "Followers" group, created in after_create callbacks. Those two groups are protected — you can't delete them, and you can't have more than one of each. But I also had to make sure that a deleted user doesn't cascade-delete their group memberships in a way that violates foreign key constraints before the groups themselves are removed. The fix was a before_destroy callback that strips the protected flags first:

after_create  :create_public_group
after_create  :create_followers_group
before_destroy :strip_protected_group_flags, prepend: true

def create_public_group
  groups.create!(name: "Public", is_public: true)
end

def strip_protected_group_flags
  groups.update_all(is_public: false, is_followers: false)
end

The prepend: true matters — without it, dependent destroys on associations run before this callback, and you'd get constraint violations.

Activity Feeds Are Harder Than They Look

I didn't want to roll my own fan-out-on-write feed system, so I integrated GetStream. It handles the mechanics: when a post is published to a group feed, it fans out to every timeline that follows that feed. My job is just to keep the follow/unfollow graph correct. That turned out to be enough work. Here's what happens when someone follows another user:

def add_to_followers_group_and_follow_feeds
  followers_group = followed.groups.find_by(is_followers: true)
  public_group    = followed.groups.find_by(is_public: true)
  target_group    = followers_group || public_group

  GroupMembership.find_or_create_by!(group: target_group, member: follower)

  timeline = StreamClient.instance.feed("timeline", follower_id.to_s)
  timeline.follow("group", target_group.id.to_s)
  timeline.follow("group", public_group.id.to_s) if public_group && target_group != public_group
end

The follower's timeline subscribes to two feeds: the followers group feed and the public group feed. That's because a post can be shared to either group and the follower should see both.

And on unfollow:

def remove_from_group_and_unfollow_feeds
  membership   = GroupMembership.find_by(member_id: follower_id, owner_id: followed_id)
  timeline     = StreamClient.instance.feed("timeline", follower_id.to_s)
  public_group = followed.groups.find_by(is_public: true)

  timeline.unfollow("group", membership.group_id.to_s)
  timeline.unfollow("group", public_group.id.to_s) if public_group && membership.group_id != public_group.id

  membership.destroy
end

There's an edge case buried in there: if someone is in the public group (their only group), you'd call unfollow on the same feed twice. Hence the if check.

The biggest mistake I made here: I stubbed the GetStream client in tests with a double. Every test passed. Then I actually ran the app and discovered that stream-ruby v6 changed its constructor from keyword args to positional args. My stub accepted anything, so it never caught it. Lesson learned — if you're going to stub an external client, at least verify the calling convention against the actual gem.

Private Accounts and the Follow Request

When a user sets their account to private, new followers need approval. This is a common feature on social platforms and sounds simple. It is not. The core model is a FollowRequest that remains in a pending state until it is approved or rejected. But the follow flow now has four distinct paths, and each one has to keep groups, feeds, and notifications in sync:

follow(public account)    → create Follow immediately
follow(private account)   → create FollowRequest, notify owner
approve(follow_request)   → destroy FollowRequest, create Follow, assign group
cancel(pending request)   → destroy FollowRequest

I made the mistake of putting most of the side-effect logic in model callbacks — after_create and after_destroy on Follow. It kept the controllers thin, which felt clean at the time. But callbacks are hard to test in isolation, and when something went wrong, the stack trace was a mess of implicit triggers.

Also, there's a subtle interaction with Devise. I added an is_invited flag to gate access during the closed beta:

def active_for_authentication?
  super && is_invited?
end

def inactive_message
  is_invited? ? super : :inactive
end

When I changed the column default from true to false, every single test broke — 204 failures at once. The sign_in helper in RSpec goes through Warden's full session validation, which calls active_for_authentication?. All my test users had is_invited: false by default, and Warden was silently blocking them. The fix was adding is_invited: true to every User.new(...) call in every request spec. Tedious, but at least the cause was obvious once I figured it out. Lesson learned - think about closed betas as early as possible.

Invisible Mode: Like u/[deleted] But Better

Vidha also has an invisible mode for the privacy fanatics. Invisible mode is a toggle users can enable from their account settings. When it's on, the user effectively doesn't exist from anyone else's perspective: their profile returns a 404, they're excluded from search results and member typeahead suggestions, and attempting to follow them returns a 404 too. It's more private than a private account — closer to "ghost mode." The implementation is blunt but honest: every entry point that could expose the user has an explicit guard.

# UsersController
def show
  raise ActiveRecord::RecordNotFound if @user != current_user && @user.invisible_mode?
  # ...
end

def follow
  head :not_found and return if @user.invisible_mode?
  # ...
end

# Search queries exclude invisible users at the DB level
User.where("username ILIKE ?", term).where(invisible_mode: false)

The raise ActiveRecord::RecordNotFound approach is intentional — it renders the same 404 page as any other missing resource, leaking no information about whether the account exists at all. However, you can still comment (shows up as "Anonymous"), and your posts can be viewed by someone with a direct link. This is to make sure you can still use the social media as intended. I suppose this might come in handy for activists or protesters who don't want to reveal their identity, yet want to post on the platform.

One thing I'm undecided on: right now, people who already follow you can still see your timeline posts even in invisible mode (the feed subscription persists). Whether that's a bug or a feature is genuinely unclear to me. Also, this feature is pretty terrifying: Anything that can leak info about an invisible user is a big no-no, and I have to make sure every new feature respects invisible users.

Currently the best approach in my mind is this:

When an invisible user joins a community (or a visible user switches to invisible), it creates a pseudo-username, like "anon-abcde". This pseudo-username is scoped to the user and community. So the same user will get different pseudo-usernames in different communities.
This pseudo-username will be visible to the mods, and they can see the list of posts and comments by this user and ban/suspend them.
Since the same user will get different pseudo-usernames in different communities, it means if someone is a moderator in two different communities, they'll not be able to link the same user in those communities.
This pseudo-username is persistent. So, if the user changes back to visible or leaves and rejoins the community, that won't generate a new one. This prevents someone from circumventing the ban by leaving and rejoining.

Communities: Like Subreddits, But Simpler

Later in the build, I added communities — shared spaces with their own post feeds, member lists, and moderation. A community post publishes to a "community" feed on GetStream instead of the author's personal group feeds. Membership works the same way: joining subscribes your timeline feed to the community's feed, while leaving unsubscribes.

The trickiest part was access control. A post in a private community should be visible only to members. A personal post should only be visible to people in the right group. Both PostsController and CommentsController need this logic. Here's the concern I extracted:

module PostVisibility
  extend ActiveSupport::Concern

  private

  def can_view_post?(post)
    if post.community_id?
      community = post.community
      return true unless community.is_private?
      return false unless current_user
      return true if current_user.id == community.creator_id
      CommunityMembership.exists?(community_id: community.id, user_id: current_user.id)
    else
      return true if current_user&.id == post.user_id
      return true if post.groups.any?(&:is_public?)
      return false unless current_user
      GroupMembership.exists?(member_id: current_user.id, group_id: post.group_ids)
    end
  end
end

I initially had variations of this logic scattered across both controllers before I noticed I was copying code and extracted it into a separate file. I should have written it in one place from the beginning. Access control sprawl is a real thing — every new context (show, edit, destroy, comment) tempts you to just paste the check inline. I'm thinking about using an authorization gem like CanCanCan or Pundit, but I'm not sure how big a rewrite it'd be or whether it'd be worth it. Lesson learned: Think about authorization and access control from the beginning, and try to reuse the logic as much as possible.

One more thing that I'm still trying to figure out: How should invisible accounts interact with community moderation? Letting invisible accounts run rampant in a community is a recipe for disaster, so moderators should have some way of telling "invisible dude A" from "invisible dude B." One approach is to let a moderator view a "community profile" of an invisible user: just the posts they have made in that particular community, plus the ban/suspend/remove buttons. But that still doesn't answer how to identify that particular user in the user list. This is something I'm thinking about very hard.

Frontend: Hotwire Over React

I chose Hotwire (Turbo + Stimulus) and deliberately avoided React. The whole point was to stay inside the Rails idiom and keep the stack simple. For most things, this worked well. Likes are a good example — toggling a like or dislike replaces just the button component in place:

def respond_with_reaction(current_kind)
  respond_to do |format|
    format.turbo_stream do
      render turbo_stream: turbo_stream.replace(
        dom_id(@likeable, :likes),
        partial: "likes/like_button",
        locals: {
          likeable: @likeable,
          liked:    current_kind == "like",
          disliked: current_kind == "dislike"
        }
      )
    end
    format.html { redirect_back fallback_location: root_path }
  end
end

No JavaScript state management, no API endpoint, no serializer. The server renders the updated partial and sends it down the wire. For the 90% case, this is genuinely fast to build.

The 10% case is where Hotwire gets awkward: complex client-side state that doesn't map cleanly to server-rendered partials. The rich text editor with group targeting, for instance, involves coordinating ActionText, a custom group selector, and a preview — all in one form. Stimulus controllers are composable, but they don't share state easily. A few times I genuinely wished I had a React app.

What I'd Tell Myself at the Start

Model the domain on paper first. The group-based visibility system is the core of the entire app. I arrived at the right data model through iteration, but a couple of hours on a whiteboard before writing any code would have saved me a week of refactoring.

Don't stub external services in tests and call it done. Stubs lie. They accept anything and catch nothing. Either test against the real service (with a sandbox account), or write a thin adapter layer that the stub actually validates against (or read the documentation well).

Access control needs a home from day one. Don't spread visibility checks across controllers. Put them somewhere dedicated — a concern, a policy object, a query object — and route everything through it.

Callbacks hide complexity, they don't eliminate it. Model callbacks feel clean until you're debugging a 12-step trigger chain at midnight. For anything that touches external services or multiple models, a service object with explicit methods is worth the extra file.

Building Vidha has been the most effective learning exercise I've done in a while. Every feature that looks simple from the outside — following someone, liking a post, showing a profile — has a graph of constraints underneath it. You don't see that graph until you try to build it yourself.

If you're thinking about building something similar, I'd say: start with the hardest domain problem and work outward from there. The framework will take care of itself.

And if you want to check out Vidha, go ahead and sign up. Then drop a comment with your username so that I can activate your account. Expect bugs, lots of them.

Vidha is a personal side project built for my own education. It is not a commercial product.

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.