The same task in every stack

How the index is built

Each of the 1,271 entries carries task tags. Those tags are normalised before clustering - stop words dropped, a narrow set of word variants collapsed, so that reverse a string, reverse string and string reversal all land in the same bucket - and the cluster becomes a page.

Two deliberate limits shape the result. First, the variant list is conservative: folders maps to directory, but merge is not mapped to join, because a git merge and a SQL join are not the same task. Second, a cluster needs at least two distinct entries to earn a page. A task answered by exactly one snippet would make a page that is a strictly worse duplicate of the section page that already holds it, so those clusters are left unpublished.

The effect of that second rule is large: the tags produce thousands of clusters and only 453 are published. What survives is, roughly, the set of tasks that at least two people writing two different sheets both thought was worth a snippet.

What the widest tasks tell you

Only three tasks are answered in five stacks, and they are all string case or slicing: lowercase, uppercase and substring, each answered in Bash, JavaScript, Python, SQL and - for the first two - HTML/CSS, because CSS has text-transform.

That is a real finding rather than a curiosity. The operations that cross the most stacks are the ones on text, because text is the only data type every one of these environments has. Lowercasing is available in a shell, a query language, a stylesheet and two general-purpose languages; nothing else in the corpus is.

One rung down, the four-stack set is where the index earns its keep. find and replace answers the same task with sed in Bash, replace() in JavaScript, replace() with a regex, and REPLACE in SQL - four genuinely different mechanisms for one intention, on one page. format date is the same shape: the date command, Python's datetime, a regex that validates the shape, and SQL date formatting. If you are porting code, this is the view you want, because the differences between the four answers are where the bugs are.

The limit of automatic clustering

The clustering is mechanical, and the largest page in the index is also the clearest illustration of what that costs. in operator carries eight entries - more than any other task page - and they are not eight answers to one question.

They are: nullish coalescing, optional chaining, nullish assignment, a property-existence check and the ternary operator from JavaScript; the walrus operator from Python; alternation from the regex sheet; and the in type guard from TypeScript. Two of the eight are about in. The rest arrived because their tags share normalised tokens with it.

That is worth knowing before you treat a task page as authoritative. The pages built on a concrete verb - copy file, remove duplicates, environment variable - are tight, because the verb constrains the tag. The pages built on a word that is a noun in one language and an operator in another are looser. The fix is not automatic: it is reading the entry titles on the page, which are shown with their stack and section for exactly that reason.

Where the index is thin, and why

The number of task pages a stack appears on varies by a factor of nine, and the shape of that variation says something about the stacks rather than about the index.

Python appears on 161 task pages and JavaScript on 147 - they are general-purpose languages that can do most things, so most tasks have an answer in them. Git appears on 18. That is not a gap in the git sheet, which has 101 entries across 11 sections; it is that git's vocabulary does not overlap with anything else. Committing, rebasing and stashing are not operations on strings, files or rows, so they cluster only with each other and with Docker's registry and tagging work.

So the index is at its best for data manipulation and its weakest for tool operation. For git, Docker or Bash as tools, the section pages are the better route - and the git undo decision tree exists precisely because that question is not a lookup.

Three ways to use it that are faster than searching

The index rewards being used as a translation table rather than as a search engine.

First: when you know the operation and not the syntax, go to the task page and read the stack you need. Every snippet on it has a copy button, and the entries are shown with the stack they belong to, so there is no ambiguity about which language the code is in.

Second: when you are porting code, read the whole task page rather than the one stack you are moving to. The differences between the answers are usually the bugs - that the Python and JavaScript answers to the same task have different edge-case behaviour is exactly what a port needs to know.

Third: when you have forgotten the name of a thing, search the task phrase rather than the API. The site's own search ranks over entry titles, task tags, syntax and examples, so a phrase like remove duplicates finds the entry even though no language calls it that.

• 453 task pages, from 1,271 entries across 152 sections and 11 stacks.
• 276 of the 453 are answered in more than one stack; 630 distinct entries appear on at least one task page.
• A task needs two or more distinct entries to get a page, which is why most tag clusters are unpublished.
• to, from and into are treated as direction markers, so string to number and number to string stay separate pages rather than merging.
• The full task index is filterable and alphabetical.

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.