Read and understand code faster with programming ligatures in Fira Code font

https://visualstudioextensions.vlasovstudio.com/2017/05/01/improve-code-readability-with-programming-ligatures-in-fira-code-font/

by icos • 9 years ago

73 42 9 years ago

visualstudioextensions.vlasovstudio.com

Something1234• 9 years ago

I'm not sure that I want my equality signs to be ligature'd together. I feel like using this might mess up alignment in a monospace font.

notamy• 9 years ago

At least with using ligatures in IntelliJ IDEA, I find that it makes zero difference as to how the monospaced font is aligned.

Chris_Newton• 9 years ago

Usually the ligatures in these fonts are designed to fill the same width as the original combination of separate characters in monospace use. That does preserve the alignment of code to either side of the ligature, but unfortunately at the expense of either making some of the symbols much wider than normal or adding a lot of extra whitespace to pad them out. For programming, the ligatured version seems quite risky if it means the only visual difference between single and double equals or underscore characters is a bit of width and/or horizontal padding.

What I would like to try is a language where = actually meant equality rather than assignment and a few other common operators like !=, ===, !==, <= and >= all appeared using the standard mathematical symbols at the same width as =, < and >. That way, some related cases would naturally line up and most lines with comparisons would become shorter and less cluttered, which seems like a modest incremental improvement in language syntax. Alas, you’d also need software and keyboard input to support that in a way that made those alternative symbols effortless and entirely predicable to use. This feels like a job for a standardised programmer’s keyboard and AltGr, except that you’d need a standardised programmer’s keyboard for each of the different languages that already uses AltGr for other purposes, and at some point it all becomes more trouble than it’s worth.

andy_ppp• 9 years ago

Very interesting but I hate this for programming, feels wrong when I'm so used to 1 char == 1 fixed with char. I'm sure I could adapt but for some reason it makes my sense of programming taste not happy. What do others think?

anotheryou• 9 years ago

It takes some time to get used to and it's annoying to place the cursor correctly to backspace from != to =.

But it looks sexy and confuses the co-workers XD. Joke aside: I actually like making my PC mine and like the look. I don't think it makes me a faster or better programmer in any way...

tylerhou• 9 years ago

Does this strike anyone else as a gimmick? I'm not sure if parsing symbols is really the limiting factor when I try to understand code.

smsm42• 9 years ago

Yes, it's a gimmick. The question whether it's a useful gimmick is an open one. I'd try it out probably, but probably it would end more confusing than helpful after the novelty wears off.

failrate• 9 years ago

It is no more a gimmick than the standard mode of rendering. However, it does have an adaptation cost. A comparable example: I went to the trouble of creating a custom key binding for my old laptop that was a standard US layout, except the numeral row was symbols by default (i.e. Press shift to get numbers), because I only used the numpad for numerals. It worked, but relearning was too painful. If I'd learned it that way from the beginning, it would just be normal.

coldtea5• 9 years ago

Doesn't have to be the limiting factor to still be an improvement.

yread• 9 years ago

I like the idea but the xml tags </ /> look horrible

aratno• 9 years ago

While these are cool for complete code snippets, they are distracting during coding. For example, the colon contextual alignment flickers as the context is typed, and that distraction alone outweighs any convenience of a merged symbol.

jobigoud• 9 years ago

Lua's not equals `~=` gets ligatured to ≃ instead of ≠. Expected but unfortunate.

abeyer• 9 years ago

Most of Lua was nicely obvious and intuitive, but ~= was always one of the weird sharp edges. I could maybe see the argument for using it if ~ was already a negation operator of some sort (like C's bitwise complement) but Lua doesn't even have that. Instead you get something needlessly non-intuitive and subject to misinterpretation by anyone who isn't a Lua native, as ~= as an ASCIIfication of ≃ is pretty common.

al4522• 9 years ago

I've been using this in IntelliJ IDEA for about a month.

The experience reminds me of adopting an anti-aliased font for coding, for the first time (many years ago). First half an hour of unfamiliarity and skepticism, then it just seems very natural, and reading code feels smoother and easier and more productive.

I absolutely cannot stand code in non-monospaced fonts, so I don't think there are any alignment problems. (The look of Fira Mono / Fira Code isn't really to my taste though, so I'm hoping for the same things to start popping up in other fonts too!)

Latty• 9 years ago

There are lots of others - my personal favourite is Monoid. http://larsenwork.com/monoid/

gvd• 9 years ago

So far this font has worked really well for me for Haskell, C++, Python. I find it very readable

gumby2• 9 years ago

This isn't really what I thought it would be. I don't want != changed to ≠ because ≠ isn't a C++ operator.

What I thought would be true ligatures ("tying together") of "&&" which could still be recognized as a pair of ampersands, but by being conjoined cleanly appear to be symbol in their own right, which is what "&&" is.

However part of the value of ligatures is symbol tightness, which is defeated by the need for a monospaced font.

Still, I'm glad people are experimenting!

coldtea5• 9 years ago

I don't want != changed to ≠ because ≠ isn't a C++ operator.

A colored != is not a C++ operator either. It's about getting our minds to differentiate symbols faster, not about whether they exist as is in some language's syntax.

gumby2• 9 years ago

Indeed, I program with syntax coloring disabled for this reason.

combatentropy• 9 years ago

I love typography and ligatures, but this introduces a layer of abstraction in your source code. I know it sounds depressingly uninternational, but I don't even like to use Unicode characters in my text files. I prefer a one-to-one mapping of keyboard button to on-screen character. Although I suppose even capital letters break that rule, so maybe one day I'll give it a whirl.

return04• 9 years ago

I would be very hesitant to use this. It's not "more intuitive" as the author would like to think. In fact , our visual system has been trained to instantly recognize a!=b in code, and I read code a lot more often than Math formulas. Plus code is not math (e.g. 1+(a>0)), confusing = with == will lead to lots of errors etc.

If I get used to this font on my machine, i will have a real problem when parsing code in another terminal/editor. Unless all the programmers in the world decide to switch to it simultaneously, this introduces a mental translation that's counterproductive.

al4522• 9 years ago

I had every one of those concerns too. In spades. And then I actually tried using it for real, and none of the concerns turned out to cause any problem in practice.

(Why would I try using something I was confident would make me less productive? Because I felt was in a rut, and was trying out disruptive changes to my workflow. For example the same day, I switched all my calculator tools to RPN. That's not gone badly either.)

zamalek• 9 years ago

What now causes a problem for me is working on code without ligatures, that's after only a few months of working with them. I also find Fira Code extremely legible as a dyslexic.

coldtea5• 9 years ago

In fact , our visual system has been trained to instantly recognize a!=b in code

Citation needed.

confusing = with == will lead to lots of errors etc

This is more about NOT confusing == with = -- and several similar characters than the opposite.

Sounds like you have thought of all kinds of arguments to not actually try it and see whether it's any good in practice -- which is how anything should be judged (unless it involves some huge risk). In other words, a priori rationalization.

If I get used to this font on my machine, i will have a real problem when parsing code in another terminal/editor.

The above argument advices to forever stick to a lowest common denominator coding toolset, lest one has to ever try to work in other environment.

How about maximizing the performance one gets from their own, and most frequently used, environment, instead of "what-ifing" for foreign systems they might have to use 1/10 of the time or less?

Plus, having a tool at our disposal and getting used to it doesn't mean we can't also do without if needed. Especially if it's a small improvement, like the one proposed by the ligatures here, and not some totally different notion that we can't ever go back to how it was without it...

return04• 9 years ago

I admit that the >= and <= looked quite more readable, but i don't see how = and == wouldnt get more easily confused. Also i do spend a lot more than 1/10th of time in different environments.

I don't understand why ppl upvoted my comment. You should try it first and report back.

Also, http://www.pallier.org/papers/Chang.Reading.2015.pdf

carterehsmith• 9 years ago

The thing is, in general, if you are promoting some change, you need to show that it brings benefits.

So the onus is on promoter - to show benefits.

The onus is _not_ on everyone in the world to show whether the idea works or not.

fineline• 9 years ago

If you give it a try, you may find your brain more adaptable than you think. Mine seems able to parse the same code in my editor (with this font) and in web-based repository viewers (with some other monospaced font) without problem.

jsjohnst• 9 years ago

Anybody else despise the look of many of these ligatures? One of the worst is the design of the ampersand.

return04• 9 years ago

I don't even think they add much to readability. If i could choose, the only ligatures i 'd like would be >= and !=

kaspiCZ• 9 years ago

In that case, I would refer you to Monoid font. I love that one. You can even select from options for e.g. ampersand, dollar, zero...

captn3m0• 9 years ago

I'm assuming this doesn't take care of context?

For eg:

String s = "A != B";

would render the ligature inside the string?

return04• 9 years ago

it doesn't unless you use a different font for strings. But it seems that would be fine in your example

altern8tif• 9 years ago

I don't think Fira Code recognizes context. It just parses the characters and renders multi-character glyphs into a single one.

So the inequality inside the string will be afforded the same treatment as an inequality anywhere else in the code.

bshimmin• 9 years ago

I quite like the "contextual vertical align". Everything else I find either visually unappealing (eg. the ampersand, as already mentioned) or outright confusing (the equality glyphs in particular).

st3fan• 9 years ago

It looks pretty but totally does not work for my brain.

cutler• 9 years ago

Ligatures aside, I tried this font in IntelliJ and found the letter spacing to be far too wide.

proyb2• 9 years ago

It doesn't took us long to decode == or >= operator naturally.

jimu• 9 years ago

wow. someone worked really hard to solve a problem that doesn't exit

wildpeaks• 9 years ago

If you want to use Fira Code in Visual Studio Code, use this in settings.json:

    "editor.fontFamily": "Fira Code"
    "editor.fontLigatures": true

mcphage• 9 years ago

It would be cool if it turned .\ into a greek lambda as well.

Read and understand code faster with programming ligatures in Fira Code font

Related Stories