Ligatures & Coding
What they can, can’t and shouldn’t do
Ligatures have been used in typography for ages and some ligatures are now characters on their own — e.g. ß and &.
Note that adding ligatures to a coding font doesn’t change your code in any way — it just changes how it’s displayed.
Ampersands can look squeezed in monospaced fonts and even more so when written next to itself — “&&” is used as “logical and operator” in many programming languages.
Creating an amp-ampersand frees up room to the other characters around it.
≥ and ≠ shown above are more intuitively understood than >= and != but aren’t normally used in coding since they’re harder to type. Ligatures combine ease of type with ease of reading.
Ligatures can be used to subtlety stress the fact that a combination of characters denote a single function.
All Hail Mrs. Minimal
Ligatures look cleaner and thus lets you focus on the actual code. Operators in code are often a combination of characters mimicking a symbol — why not just display the actual symbol everyone already knows?
Modern languages like Swift and social coding like GitHub have made emojis more ubiquitous in coding but a lot of languages don’t support those. I often write “somethingIcon” in code when making a reference to said icon. Actually displaying the icon in the code not only makes it easier to find when skimming — it also makes the code more compact.
I’ve only added 4 icons just to test it and it’s important to note that:
Icons should only be used alone when they leave no room for (mis)interpretation
You win some and you lose some but there are a couple of things to keep in mind when doing ligatures in code.
Some fonts group/glue things together for reasons mentioned above but does so at the risk of reducing how easy it is to tell two symbols apart when glancing through code — e.g. “=” vs “==”.
I’ve chosen not to glue equal signs together and instead I’ve increase tracking.
Ligatures such as ≠ aren’t intuitively edited. A way around this is to disable ligatures for highlighted text like shown on the left (what I’m currently doing).
Turning all ligatures off when highlighted is a crude approach though — from my example above the “==” ligature would actually be harder to edit when turned off so instead of just turning ligatures off I’ll probably add “editable” stylistic alternates only where it’s needed.
Remember to turn off ligatures for web/educational use and when taking screenshots.
Not all editors support ligatures but a lot do.
What about ligatures that span over multiple glyphs? A common approach is to create ligatures 2, 3, 4 etc. times the monospaced width so that
ligaWidth >= monospaceWidth && ligaWidth % monospaceWidth = 0
but then the font isn’t a true monospaced font anymore. See this discussion for details on that subject.
Creating pseudo something bugs the purist in me and some VIMs only accept true monospaced fonts.
I’ve used the word ligatures (too?) many times but I’ve done so because it’s a familiar concept. What I’m actually advocating is using a combination of contextual alternates + ligatures.
This allows for all glyphs to have the same width. It’s a bit technical but my tweet below shows how I’ve done it so far. See the actual feature file for more details.
I’ll write more articles about coding and typography in the future so follow me here or on twitter for updates.
You can configure and download Monoid on larsenwork.com/monoid and the issue regarding ligatures is #25 where you can see the ligatures I’ve added so far — I’d love to get some opinions/input on the subject.
A freelance designer/developer/typographer currently living in Copenhagen looking for a more 8–17 job.