How this cheat sheet is organized

The three levels

A sheet is a stack: Bash & Linux, Docker, Git, HTML & CSS, Interview Prep, JavaScript, Python, React, Regular Expressions, SQL and TypeScript. A sheet page lists its sections; a section page holds the entries and is the page most search traffic lands on.

Section sizes are deliberately small - between 5 and 16 entries - because a section page is meant to be readable in one pass. The largest sheet is HTML & CSS at 156 entries over 18 sections; the smallest is the regex sheet at 86 over 11.

Every entry has its own anchor on its section page, so a link can point at one snippet rather than at a page of them. The guides here use that: when a guide names an entry, the link goes straight to it.

What an entry contains

Six fields, four of which are on every single entry.

Title, syntax, example and note are populated on all 1,271 entries. Output - what the code prints - is on 722 of them, because plenty of snippets have nothing to print. The note is the field that does the real work: it is where the caveat lives, and in this corpus the caveat is usually the reason the entry exists at all.

The sixth field is intentTags, the task labels that drive the index: 5,831 tags over the 1,271 entries, averaging 4.6 each and never more than 7. Each entry has its own set, which is why the clustering in the next section works at all.

Output is rendered without syntax highlighting, deliberately. Program output is not source code, and painting it with a language grammar invents meaning that is not there - a # in a shell transcript is a prompt, not a comment.

The task index, built sideways

The 5,401 distinct written tags are normalised and clustered, and each surviving cluster becomes a task page: 453 of them, 276 answered in more than one stack. A cluster needs two or more distinct entries to be published, because a page wrapping one snippet would be a thinner duplicate of the section page that already holds it. Most clusters hold exactly one entry and are therefore not published at all.

The normalisation is narrow on purpose. Stop words go, a small set of spelling and plural variants collapse - folders to directory, reversing to reverse - and that is all. Cross-concept synonyms were tried and rejected: mapping merge to join would file a git merge with a SQL join, which is a different operation with a similar name.

One exception to the word-order-does-not-matter rule: to, from and into are treated as direction markers when there is content on both sides of them, so string to number and number to string stay separate pages instead of collapsing into one. The cross-stack guide goes further into what the index is good for and where it is loose.

How search ranks

Search is task-first, which in practice means the ranking is weighted towards the two fields a person types into: the entry title and the task tags.

An exact title match scores highest, a title that starts with your term next, a title that contains it after that. An exact tag match scores close to a title prefix match - which is the mechanism that makes a phrase like center a div work even though no entry is titled that. Everything else - syntax, example, note, section and sheet name - is searched too, but scores an order of magnitude lower, so a term that happens to appear in a code sample never outranks one in a title.

Two practical consequences. Search the task, not the API, when you do not know the API. And search a distinctive word rather than a phrase when you do: one precise term beats four vague ones, because every term you add has to match somewhere for the entry to be returned at all.

• Exact title match: the strongest signal.
• Exact task-tag match: close behind a title prefix match.
• A hit anywhere else in the entry: counted, but weakly.
• Matching the whole phrase in a title or tag adds a bonus on top.
• Every term must match something, somewhere, or the entry is not returned.

Offline, free, and local

The whole site is statically generated and installable as a progressive web app, so once a page has been visited it is available without a network. There is no backend to be unavailable.

It is also free in full. Every sheet, every section page, every task page, the search, the copy buttons, favourites and notes - all of it, with no paid tier and nothing to buy. There is no account, which is the other half of the same decision: favourites and notes are stored in your own browser, not on a server, and that is the only place they exist. Clearing site data clears them, and they do not follow you to another device.

Nothing here tracks you between pages for advertising. The practical trade-off of the local-only model is the one worth stating plainly: your notes are private because nobody else can read them, including us, and un-backed-up because nobody else is holding a copy. The settings page exports them as a file for exactly that reason.

What the data model does not do

Three gaps, stated because a reference that hides them is harder to trust.

First, there is an errorStrings field on every entry and it is empty on all 1,271. It was designed for searching by error message - paste TypeError: Cannot read properties of undefined and get the entry that explains it - which is probably the highest-intent query in developer search, and it was never populated. The search ranking still scores the field, so filling it would work; until then it does nothing, and this site's machine-readable description no longer advertises it as a feature.

Second, snippets have no language of their own: the stack a snippet belongs to is used as a proxy, mapping the eleven stack ids onto six highlighter grammars. That is accurate in practice - every entry on the Python sheet is Python - with one exception the code handles specially. On the regex sheet only the syntax field is a bare pattern; its 86 examples are host-language calls in JavaScript or Python, so they are highlighted with a mixed grammar rather than as regex, which would otherwise turn every parenthesis in ordinary JavaScript into a metacharacter.

Third, the corpus is a cheat sheet and not a manual. An entry is a snippet with a caveat, not an explanation of a language feature from first principles. Where a question needs more than that - which of four git commands to use, why a regex hangs - that is what the guides are for, and there are seven of them against 1,271 entries, so the coverage is deliberately narrow.

• errorStrings: present in the schema, empty on all 1,271 entries.
• Highlighting is per-stack, six grammars across eleven stacks.
• output is never highlighted - it is not source.
• Favourites and notes are browser-local and not backed up; export them from settings.
• No paid tier, no account, no server-side storage of anything you do here.

Questions people ask

Where this comes from

Every code block above is rendered from this site’s own entry data at build time, with a link to the entry it came from, and every count in the prose is derived from the same file. How this cheat sheet is organized explains the structure and says what the corpus does not cover.