Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IMO syntax coloring lessens the cognitive load. What is "high level code". You are telling a machine what to do and to do it as fast as possible. Can you still make money telling a machine what to do but not as fast, depends but most likely. We code to ultimately make money in one form or another. Whether you keep that money or put it towards altruistic causes is independent of the shared commonality.


I have to agree. Syntax highlighting lets me recognise patterns in code without having to read it, and I actively avoid reading details I don't need.

(To me that is also what annoy me about IDE's - I want to focus on the shape of the code, not other stuff. When I focus on code, I want that code to be all that exists in my mind at that time; but I suspect whether or not you like IDE's is orthogonal to how you like your code presented)

But I also feel like there is an interesting range within developers from those of us who pattern match skim and "zoom" in on details to those developers who read code in detail, and I'm not sure those of us on different sides of that spectrum see perceptual load the same way.

On one end you find people like me who are purist about syntax and presentation because we're extremely conscious about avoiding having to read everything. E.g. I remember code by overall visual shape, and I can hold a lot of that in my head at once, but I don't remember what it says. I know where to find things rapidly, but not the details. I never try to remember the details.

On the other extreme you find people with like their code to look like K or J "line noise" or mathematical notation because it's short and compact which helps when they're deciphering the code symbol by symbol.

To me, the latter is the height of perceptual load, because I can't just look at it and have a rough idea what it might do, but I understand that some instead see it as stripping away extraneous details.


Interesting that you mention shapes, because for me that extends to keywords and stuff, e.g I don't care if def or class is highlighted, the shape of the code and the tokens tell me that, so it being coloured is redundant and thus useless cognitive load most of the time.

The main use I have of syntax highlighting is instead making sure the computer and I agree on these tokens being what I expect them to be; it's a form of live parsing error control, a direct feedback loop, not a way for me to parse code.

My ideal colour scheme is none at all, save for subduing comments (and being able to toggle that, subduing code instead) and colouring things in/around errors when a mismatch is detected (typically, unbalanced delimiters)


We should organise a study of our own: does syntax highlighting help or hinder and does the answer change based on your level of ADHD traits.

Could be quite interesting!


I have been diagnosed with ADHD and got an especially bad score for working memory.

I find myself tired out really quickly by a lack of syntax highlighting.

With syntax highlighting, I feel like I am not really reading the code anymore, but instead just registering the patterns and parsing the color tokens.

I think the most important aspect for me, is that I don't spend time reading where a token starts and ends. Ex.: If I wanna check the function name, I just have to read the only yellow thing in around this area.

I can register the tokens on a whole page in seconds, if the code isn't too dense. I just tried the same with syntax highlighting disabled and would say that I took about twice as long to parse the entire page. (I used a different, but similar file from a microcontroller HAL)


It's not adhd specific but https://arxiv.org/abs/2008.06030

After reading this I implemented a code theme based primarily around typographic variation like weight rather than color. It uses only two colors (black and deep purple) in two weights and one italic each. I have pretty severe adhd and it's hard to judge but after using it for a few months I think this is better for me. Previously I had been using solarized light for nearly a decade for probably similar reasons.

Nano emacs was created by the author of that paper and its default themes are based on it, if you want to try it without committing to hand-rolling a theme. Personally I found that one too "light" (typographically, not color) but I also have relatively poor vision and like a large and heavy font.

https://github.com/rougier/nano-emacs


I also immediately thought of Nano Emacs when I saw this article.

There is a short talk (6min) from EmacsConf 2021 where the creator of Nano Emacs talks about his reasons for designing a simpler interface, I found it really interesting:

https://emacsconf.org/2021/talks/design/


Yeah it was kind of a mind blower to me. I'm not in a big hurry to settle an opinion but I have a feeling these are ideas that I'll be exploring and influenced by for the rest of my career.


Note: there is an effect that less eligible font makes for deeper understanding (it makes the text harder to read thus your conscious has the time to process before your fast intuitive system I jumps to conclusions).

While skimming code (i.e., most of the time), syntax highlighting is useful. But it may be also useful to turn it off occasionally, to read some parts more thoroughly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: