Code/Tech Snippets - Alt Codes & Unicode

This table gathers the characters that come up when writing about code rather than writing code: the backtick that opens a fenced block or inline span in Markdown, the arrows used in documentation and diagrams, the ellipsis, the curly quotation marks, and the invisible spaces that control layout. The mix reflects a real need — technical writing sits between plain code, where only ASCII is safe, and prose, where proper typography is expected.

The backtick is the one people hunt for most. It opens inline code in Markdown, wraps template literals in JavaScript, and performs command substitution in shell scripts. On most keyboards it shares a key with the tilde at the top left, but on several international layouts it is a dead key — pressing it produces nothing until you press another key, which then receives a grave accent. On a French AZERTY or a US International layout, pressing backtick then space is the usual way to get a literal one, and this catches out developers switching machines constantly.

The single most important rule in this table is where not to use these characters. Curly quotation marks and the true ellipsis belong in prose about code and must never appear inside code itself. A smart-quote substitution inside a code block is one of the most common and most confusing bugs in technical writing: the code looks correct, but the string delimiters are U+201C and U+201D rather than the ASCII quote, and the interpreter rejects it with an error that points nowhere useful. Word processors and some note apps apply this substitution automatically, which is why pasting code through them corrupts it. If a copied snippet fails with a syntax error near a string, check the quote characters first.

The arrows earn their place in documentation. → is standard for describing navigation paths and transformations — File → Export, or input → output — and reads far better than a hyphen and a greater-than sign, which many readers parse as an operator. The bidirectional ↔ marks two-way relationships in architecture notes and diagrams. These are the only arrows most technical writing needs.

The two invisible characters at the end of the table solve formatting problems in documentation. The non-breaking space keeps a command name from splitting across a line, or holds a version number to its product name. The narrow no-break space does the same in tighter typographic settings. Both are safe in prose and dangerous in code, for the same reason smart quotes are: a non-breaking space inside a command line looks exactly like a normal space and will not work. When a copied terminal command fails inexplicably, an invisible U+00A0 picked up from a web page is a frequent culprit, and retyping the spaces is usually faster than finding it.