8 ms·

Syntax Highlighting Is Backwards (2018)

274 points by pcr910303 7y ago

uxp 7y ago
Do I have some weird rendering issue with this website, or do both of these snippets of code have terrible readability and highlighting? If I had to write code using an IDE or editor with this scheme I'd quit my career and go into small engine repair. https://imgur.com/a/vS2EldV https://imgur.com/a/vS2EldV
- saagarjha 7y ago
  The text is black for me on my iPhone.
  - FPGAhacker 7y ago
    It might be a dark mode thing. Edit: Yep, dark mode mangled the code snippets.
    - saagarjha 7y ago
      It is!
- FPGAhacker 7y ago
  That’s what it looked like for me. I thought maybe it looked illegible to me due to red-green color deficiency.
  - FPGAhacker 7y ago
    It’s a dark mode thing. Looks normalish with dark mode off.
  - jeltz 7y ago
    Nope, I am not color blind and it is very hard to read for me too.
- jeltz 7y ago
  Nope, it looks the same to me and I have a screen with high contrast and high brightness. Both his examples are very hard to read. And I have done color blindness tests and know I am not color blind. Another thing: I think one thing he is missing is how important it is to see at a glance where function definitions are and where possible early returns are. The first example highlights def (function definitions), return (possible early return) and the return type (arguably not that important in most cases).
- SahAssar 7y ago
  I think this is what it is supposed to look like: https://imgur.com/a/OHkBb8Q https://imgur.com/a/OHkBb8Q
- pcr910303 7y ago
  I'm pretty sure it's b.c. you have dark mode turned on & the CSS didn't consider code snippets. Try turning them off, it'll look much better.
  - deleted 7y ago
    [deleted]
  - jeltz 7y ago
    Thanks, it is better now but still not very good.
  - Mathnerd314 7y ago
    ui.systemUsesDarkTheme = 0 for FF users.
    - mercora 7y ago
      I use "widget.content.gtk-theme-override;Adwaita:light" to fix commonly invalid assumptions about default colors and appearances. It overrides the GTK theme used to render page content and still allows to use a dark theme (or whatever you want) for UI components.
- czr 7y ago
  hack to switch to light mode, if you don't want to do it systemwide (paste into console): Array.from(document.styleSheets).forEach(ss => Array.from(ss.rules).forEach((ssr,i) => {if (ssr.cssText && ssr.cssText.includes("dark")) {ssr.parentStyleSheet.deleteRule(i)}}))
- benkuhn 7y ago
  Sorry about that! I built dark mode after writing this post and it broke the main text color inside the `pre`s, which should have been #222. Should be fixed now.
whalesalad 7y ago
I totally agree with the sentiment of the author but the execution is really terrible. I'm not sure how the end product is at all better. It's appearing as like #CCC or #EEE on a white background. Screenshot: https://s3.whalesalad.com/images/hn/syntax.png https://s3.whalesalad.com/images/hn/syntax.png My favorite color scheme for a long time has been Made of Code, which I have slowly tweaked over the years. It has particularly great rendering of comments, where the line of the comment has a background color that takes up the entire row. Example 1: https://s3.whalesalad.com/syntax/made-of-code-tweaked.png https://s3.whalesalad.com/syntax/made-of-code-tweaked.png Example 2: https://s3.whalesalad.com/syntax/made-of-code-tweaked-2.png https://s3.whalesalad.com/syntax/made-of-code-tweaked-2.png Theme file (Textmate/Sublime): https://s3.whalesalad.com/syntax/whalesalad-2.tmTheme https://s3.whalesalad.com/syntax/whalesalad-2.tmTheme
- bastawhiz 7y ago
  Try disabling dark mode on your device.
- rozab 7y ago
  That theme looks very good from a practical standpoint, there's a lot of nicely contrasting colours. Do you personally find it aesthetically appealing though? I don't really. For me aesthetics is a big factor. I've always liked having my computer set up the way I like. I don't have anything on my desk, so I think it's the equivalent of desk decorations. It makes me feel comfy and at home and thus more productive. My favourite theme right now is Hopscotch. [0] I also find the reduced contrast also makes it easier to look at for long periods. [0]: https://github.com/idleberg/Hopscotch https://github.com/idleberg/Hopscotch
Longhanks 7y ago
How is this gray on gray on black better than just coloring the method name differently? Seems to me the author just isn't happy with the color scheme, but discarding syntax highlighting alltogether seems like a step too far. Different colors definitely help me to quickly scan code.
kissgyorgy 7y ago
This is on par with what Uncle Bob said in an episode of Clean Code. He went as far as saying comments should be red!
beaconstudios 7y ago
this seems fundamentally similar to the idea of literate code, where the domain and context-specific information like comments (and in TFA, function and variable names) are put front and center. This approach makes more sense to me though, as literate programming emphasises writing a book that incidentally contains source code, whereas the idea of valuable comments nowadays is closer to highlighting concerns or explaining functionality that isn't evident or easy to read in the code itself. Or in other words; this sounds like a good idea! I wonder if it would help decrease the incidence of people ignoring and not updating comments though, as a developer's focus is often primarily on correcting the code and thus even with bolding the comments may end up falling into the same trap as banner blindness[1]. [1] https://en.wikipedia.org/wiki/Banner_blindness https://en.wikipedia.org/wiki/Banner_blindness
bastawhiz 7y ago
This largely seems like an issue with the author's IDE or theme, not an issue with syntax highlighting. I immediately assumed the first screenshot was what they were proposing since it's not like the syntax highlighting that I have used in vi, sublime, visual studio, or vscode. The actual proposal, to my eyes, removes highlighting entirely: I can't differentiate the shades well at all, and the "bold" commented text is even less visually distinct than in the original. Semi-related: do folks actually use very low contrast themes like the one in the screenshot? My vision is better than 20 20 and reading light gray on white (or dark gray on black, for that matter) is a terrible strain on my eyes. Edit: it appears the author has a dark mode theme on their blog which changes the colors of the screenshots
- Mikeb85 7y ago
  I personally like relatively low contrast colours on a dark background. High contrast themes put strain on my eyes.
- squeaky-clean 7y ago
  PyCharm is extremely configurable. I've probably spent a whole day or more setting up my preferred syntax highlighting and keybindings. I think the default highlighting is fine because it's what's best for beginners, highlighting language keywords and such.
- csdvrx 7y ago
  Yes, I use a low contrast theme, light grey on yellow. My vim is Solarized based so I can invert colors at night and get more contrast by collapsing the RGB values into just red using NegativeScreen. My bash is more custom: to be even lower contrast, I don't use colors except for when commands return with an error code. Instead, I use font attributes a lot (bold, italics, faint, etc) and I timestamp my commands so when I check my records I can easily find which parts took me the longest to think and do. The command I am typing has the current directory in bold to quickly remind me as I usually have several terminals opened. Here is what my bash (where I spend the most time in) and vi looks like: https://raw.githubusercontent.com/csdvrx/sixel-tmux/master/sixel-tmux.jpg https://raw.githubusercontent.com/csdvrx/sixel-tmux/master/s... My bash has changed to match vi: the # prompt and red error codes now use the background color with: \e[2;48;2;215;215;175m\]#[\e[0m\]
akkartik 7y ago
Not all comments are worth highlighting: http://akkartik.name/post/2012-11-24-18-10-36-soc http://akkartik.name/post/2012-11-24-18-10-36-soc For the last 6 years I use three colors for comments: https://i.imgur.com/vU783Xo_d.jpg?maxwidth=640&shape=thumb&fidelity=medium https://i.imgur.com/vU783Xo_d.jpg?maxwidth=640&shape=thumb&f... If you have a configurable editor you can find more useful things to highlight in the code as well: https://www.reddit.com/r/programming/comments/1w76um/comment/cezpios https://www.reddit.com/r/programming/comments/1w76um/comment...
- saagarjha 7y ago
  Your second image is really blurry :(
  - akkartik 7y ago
    Yeah, fixed now.
    - empyrical 7y ago
      The _d in the imgur link renders it as a thumbnail, here's the full res version: https://i.imgur.com/vU783Xo.jpg https://i.imgur.com/vU783Xo.jpg
      - akkartik 7y ago
        Thank you! I actually started out with that link, but it rendered with all the usual Imgur cruft on my phone :/
- SlowRobotAhead 7y ago
  > It seems those who write sparse comments want them to pop out of the screen, and those who comment more heavily like to provide a background hum of human commentary that's useful to read in certain contexts and otherwise easy to filter out. This has slightly increased the number of comments overall and while I think quality has gone way up, I don’t want them more visible to the point of distraction. Yep. Put me in the latter camp. If you made my comments more visable it would be highly distracting. Thinking about it like commentary is good because along with WHY comments over WHAT comments, I’ve been making an effort to describe INTENT for future readers (me).
mjburgess 7y ago
The quality of the execution of the author's idea is a good guide to the quality of the idea itself. In general, comments are not so informative and the code is self-documenting. ie., the code itself should be emphasized for comprehension. The author misses the purpose of highlighting: to supply grammatical information where the language itself is deficient. Since we have plenty of experience with english grammar, we do not need help.
lgeorget 7y ago
As with a lot of things, this is ultimately a matter of personal preferences, and the compiler could not care less about how your code is displayed in your editor. So, the question is not whether is's "backwards" or not, it's only a matter a finding the highlighting theme that subjectively suits you. In my case, I prefer having the keywords highlighted and comments less visible than the code. Why? Because code is not something I read linearly. Having the syntactic markers highlighted helps me visually navigate from blocks to blocks. And it makes it much easier to spot missing curly braces, parentheses, etc.
- jeltz 7y ago
  Same preference here. I use highlighted keywords to navigate and find stuff quickly in files. Especially important is highlight of some keywords like "return" so I do not miss any early returns.
- SlowRobotAhead 7y ago
  This is a good counter argument to the article. I know instantly what a switch statement does, but if I have big bold markers for where a switch and it’s cases are, that helps me jump to the block I’m looking for. In the case of faint comments, I may need to slow down and actually read them if they’re a little less visible. I also know instantly that comments aren’t code and I don’t want all my code faint so just them being different from each other is enough for me. Article makes good points but doesn’t seem like it’s for me.
  - dr_zoidberg 7y ago
    I've seen a few editors[0] highlight certain words in comments like "TODO", "BUG", "FIXME", etc. It depends on the parser that the higlighter uses (some regex based may have limitations here), but it does exist. [0] pycharm and vscode come to mind because I use them the most, but other that I don't recall also do it edit: a couple of typos
    - SPBS 7y ago
      Vim highlights those by default too. I had no idea that was a default in vscode as well
marktangotango 7y ago
I read this as the author advocating for some form of "comments first" development philosophy. As such, I'd like to submit this well known bit of work by Knuth for consideration (by anyone not already familiar with it): https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming IME that gives all a starting point or base line for discussions around "what can more/good/better comments and support for documentation do for me".
xwdv 7y ago
I used to put comments in a more faded out color because most aren’t worth reading and they certainly aren’t worth highlighting.
- SlowRobotAhead 7y ago
  If you are writing comments that aren’t worth reading, what is the point at all? WHY not WHAT really helped me out. WHY is this thing here instead of WHAT it is can give a line like i++; a vastly different comment and implication for the reader.
  - xwdv 7y ago
    Comments can go rapidly out of date and rarely get updated properly to reflect new changes in code. As a result, comments lie and can’t be trusted, and the only source of truth is actual code.
    - nikisweeting 7y ago
      I've people on previous teams that thought this, and their comments were consistently the ones that were the most out-of-date because they never valued fixing them. If you value comment accuracy during PR reviews then you're less likely to end up in that situation in the first place.
      - throwaway40324 7y ago
        This. I totally agree. One fallacy I've seen is a reviewer only looking at the diff on Github, where a minor change in the middle of a function is made, and they don't expand the diff to notice that the new change completely invalidates a comment, params, call signature, return value..etc.
klodolph 7y ago
Maybe for internal comments. I like having different styles for docstring comments and other comments. /** Frobnicate the weevil with the given ID and return 0 on success. * * Locks the weevil during frobnication, which may take a while. */ int weevil_frobnicate(const char *id); The most important part here is the function definition and its types and parameters. Usually, when I'm looking for a function, the name and type is enough to find what I'm looking for. So I want the function declaration to stand out and the docstring to be faded.
twotwotwo 7y ago
The most intriguing version I've heard of this was also based on the feeling that it's already easy to scan for keywords and structure; they went a different direction, using color to make different things (especially confusable ones) look different: https://wordsandbuttons.online/lexical_differential_highlighting_instead_of_syntax_highlighting.html https://wordsandbuttons.online/lexical_differential_highligh... I don't feel like I know how/if highlighting helps, so all I can really say is seems interesting. I think some of the problems commenters are having with the color scheme are because the site has a dark mode and contrast might be worse when it's on. Maybe in that mode text colors meant for a dark background are still getting applied in the white-backgrounded code fragments.
dystroy 7y ago
We're really good at parsing code, thanks to languages designed to be easy to read and to our style guides (unless we don't have one, of course). Highlighting keywords is uselessly tiring for the eyes IMO. What matters most is to separate code from what's not code and which doesn't follow the same rules: comments and string-like literals. In my vim color scheme (https://github.com/Canop/patine https://github.com/Canop/patine) I only have three colors: one for code, one for comments, one for strings, and I find reading the code easier and less tiring this way.
- z5h 7y ago
  Yes yes yes! For a long time this three color style was my philosophy. It's all you need. I'm currently (with new laptop) doing a thing where I try to install/customize as little as possible. This means not using that philosophy, but not because it didn't work.
- mikelward 7y ago
  Me too. Plus a color for errors, and one for line numbers and other non-code parts of the UI. https://github.com/mikelward/conf/blob/master/vim/colors/basic.vim https://github.com/mikelward/conf/blob/master/vim/colors/bas... And a similar theme I wrote for vscode. https://marketplace.visualstudio.com/items?itemName=mikelward.theme-plainlight https://marketplace.visualstudio.com/items?itemName=mikelwar...
gorgoiler 7y ago
It’s definitely subjective. For me, I see highlighted keywords as the anchors around which the creative process occurs.
jbverschoor 7y ago
In eclipse comments such as TODO and FIXME were always bold. The thing with important comments is that they are verbose, so they can span for example 5 lines (or 3 in this example). Because of this, they already have more attention. I think most themes are pretty sane. There's a mixture of blue, darkblue and black for keywords and methods/vars. For contrast, strings and numbers are red and green. Comments are green, so they stand out enough for me.
smnrchrds 7y ago
This is certainly true for learnxinyminutes.com The comments are the most important part of the document, yet they are barely visible due to colour and contrast chosen by syntax highlighter. Example: https://learnxinyminutes.com/docs/csharp/ https://learnxinyminutes.com/docs/csharp/
clatan 7y ago
Yeah... No thank you. I mostly look at/work in code
foobar_ 7y ago
I've been using nosyntax for a while ... this seems like an good addition to that.
czr 7y ago
for those interested, there's a longer discussion of this idea at https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/ https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... (2014)
franciscop 7y ago
I totally agree, made a while ago a snippet for Atom with syntax highlighting based on a similar article [1] that will make comments bright pink (meta-tweet with the code in effect): https://twitter.com/FPresencia/status/1133733608785473536 https://twitter.com/FPresencia/status/1133733608785473536 For copy/paste (in Atom -> Stylesheet...): .syntax--comment, .syntax--punctuation.syntax--definition.syntax--comment, .syntax--comment .syntax--markup.syntax--link { color: rgba(255, 51, 255, 0.8); } .syntax--comment.syntax--block, .syntax--comment.syntax--line { background: rgba(255, 51, 255, 0.1); } [1] https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/ https://jameshfisher.com/2014/05/11/your-syntax-highlighter-...
- PretzelFisch 7y ago
  It doesn't look like you completely agree, you kept the code blocks readable rather then flipping their styles like the author.
tengbretson 7y ago
This sounds nice in an idealistic situation where comments are limited to identifying important gotchas, but in my experience there's way too many bullshit comments in most software
buboard 7y ago
Highlighting is meant to create "visual handles" on the code so your eyes can quickly jump to beginning/end of function/loop to figure out the scope of the comment. If you put the comment first , it's like replacing the floor numbers in an elevator with the warning signs. At most , you'd highlight just the word "WARNING:" or "TODO:" etc. Anything more is clutter
PretzelFisch 7y ago
The trouble is with the propagation of poor template systems auto generating relevant comments and new/junior developers writing comments that are just what the code does as opposed to functionally important. Since this represents the bulk of comments most themes have started to contrast them out so that the actual code is more prominent But to fix this the author should just find a better contrast for comments in their chosen theme so they are just as readable as code. The idea you would make comments more prominent and the code harder to read leads me to believe they don't write much code.
TeMPOraL 7y ago
Personally, I tweaked the default syntax coloring to deemphasise only punctuation (e.g. parentheses), and emphasise comments (for the reason outlined in the article). I don't think it's necessarily a good idea to deemphasize keywords - they often imply change in the evaluation semantics, so it's good to be able to spot them easily when scanning.
mdip 7y ago
I came to the conclusion about comments about a year ago for a completely different reason ... though, ultimately, ended up saving me in the way he mentioned: In my IDE, comments are bolded, italicized and red with a dashed underline and a mark on the scrollbar (thanks Rider). It's extreme, but it works perfectly with my code and commenting style. Doc comments are not treated this way, only inline comments, of which you may find one or two in an entire project of mine. I did away with non-doc comments a long while ago, and originally set this style in order to have any I'd missed stand out and "be ugly" so that I'd move the comments into a "remarks" section of the doc comments. The side-effect, though, is that when I'd run into a comment that was a "here be dragons", it'd stand out so strongly that you couldn't miss the warning. So I left it that way for good.
benkuhn 7y ago
Sorry to everyone who complained about the colors! I added a dark mode recently and it broke the custom CSS in this post. I've fixed it now. (Well, you may still not believe it's fixed :P )
zedgerman 7y ago
SourceInsight[1] always had an interesting perspective on this. It seems popular with the low-level C++ crowd in particular. [1] https://www.sourceinsight.com/doc/v4/userguide/index.html#t=Manual%2FConcepts%2FSyntax_Formatting_and_Styles.htm https://www.sourceinsight.com/doc/v4/userguide/index.html#t=...
pixelmonkey 7y ago
I've watched a lot of talks on Python by @dabeaz (David Beazley) and attended a couple of his in-person courses in Chicago. I was always amazed about the fact that he used emacs with no syntax highlighting, no line numbers, etc. as his live coding buffer. When I asked him about it one time, his answer really made me think hard about my own "souped up" vim setup. He said, "The hard part of coding in Python isn't getting the syntax right; the hard part is getting the logic right. Syntax highlighting makes me focus on the syntax when I should be focusing on the logic." I didn't change my own setup, but it did get me to question my default assumptions on the practice. That said, one specific example when syntax highlighting is very useful IMO is "rainbow parentheses". Especially when coding in Scheme, Racket, Lisp, Clojure, etc. But also for matching parens in fluent APIs and for matching braces in JSON.
- gav 7y ago
  I spent a long time without syntax highlighting, or very minor highlighting (parenthesis/brackets/braces) but at a conference somebody told me that looking at monochrome text all day was depressing and that adding color with syntax highlighting made things less gloomy. Since then I've liked adding a little color.
  - pixelmonkey 7y ago
    The aesthetic feeling of a nicely colored buffer is the reason I keep my syntax highlighting around! It just feels nice.
- CmdrKrool 7y ago
  A counter response to Beazley's quote might be, "syntax highlighting helps the syntax get out of the way so that I can focus on the logic". I suppose that's exactly what's happening in your "rainbow parentheses" case when you have way better things to do than squinting to count those little bleeders.
astrobe_ 7y ago
And one could say it is also inside-out: https://en.wikipedia.org/wiki/ColorForth https://en.wikipedia.org/wiki/ColorForth Basically in ColorForth, color is sort of part of the syntax. For instance when you want to define a new function, you would use the red color to type its name.
BurningFrog 7y ago
I mostly disagree. If your codebase have good, sparse and accurate comments this could make sense. But I don't see a lot of that. It's mostly low quality and outdated. I want to see the code, because that's what's actually being executed.
a-nikolaev 7y ago
I have this color scheme for Vim with keywords greyed, in favor of other parts of the program syntax that look brighter in comparison: https://github.com/a-nikolaev/vim-boltzmann https://github.com/a-nikolaev/vim-boltzmann - keywords are grey - comments are red - constant and literals are green and blue - main text is off-white Keywords often can be guessed from the overall structure of the program block and its indentation, especially in languages like OCaml. So making them bright only adds noise, distracting from what's important.
m4r35n357 7y ago
Yep, everybody's got one.
beaker52 7y ago
Drawing attention to language constructs like if and return helps you visually identify patterns. When you need to know details you look into the specific code. Highlighting the noisiest and least uniform parts of code is probably not what I really want. I don't want to draw references from an entire book in title case, with tiny section and chapter titles for example. Highlighting helps me identify code from a distance, it doesn't help me read it. It's about visual cues that eventually form into heuristics that save me time as I roam around a codebase. "Oh this is one of those" "that's not the kind of function that I'm looking for"
- michaelcampbell 7y ago
  Yup, highlighting is for code shape, not content.
- chadlavi 7y ago
  This. I really couldn't disagree more with the linked article on this.
creatonez 7y ago
Of note is that Kate editor, when used with a language server, has an interesting approach to syntax highlighting. It has something called rainbow highlighting, which colors each variable/class/whatever uniquely.
- jobigoud 7y ago
  Interesting! Are the keywords also having their own color each, or are they grouped in a single color?
- recursivecaveat 7y ago
  I have also heard this called 'semantic highlighting' for anyone searching for a plugin for their editor. Not sure if any do this, but it would be interesting to try a version that assigns bands of colours to different types of symbols. Eg earthy colours for parameters, neon for locals, pastels for globals, etc.
  - nikisweeting 7y ago
    There's a plugin that does semantic highlighting for Sublime, then Sublime added native support for it a little while ago. Since then I haven't seen any new plugins that take advantage of the new native Sublime functionality though.
- squeaky-clean 7y ago
  You can enable this in PyCharm too (the IDE from the post) and probably every other IntelliJ variant. I believe it takes a hash of the variable name and turns it into a color? Because it will consistently keep color for the same tokens across projects and files. Really useful! Though maybe I installed a plugin to do this, I'm away from ny laptop at the moment (happy holidays).
powerapple 7y ago
I had the same thought a few years back. I think it depends on are you 'reading' code or 'writing' code. When reading code, I want to read comments rather than ignoring them. When writing code, syntax highlighting is kind of doing spell checks for you. I don't think they are really useful, but you can't go back once you have them.
hzhou321 7y ago
It is not backward. The keywords to a program are like skeletons to a body and highways to a city. While we agree that the organs or even muscles are more meaningful to a body's function and the business inside buildings off the road are the essence of a city, skeletons and roads provide structures and makes it possible for those "meanings" to render. Without it, one can't practically dive into the more complex and meaningful stuff without getting lost. While the keywords are not the real meaningful part of code, it contributes the most to organize and to manage the complexity of code. So functionally, in terms of managing code and making writing and reading sophisticated programs possible, keywords are the most important parts.
laurent123456 7y ago
(2018)
- dang 7y ago
  Added. Thanks!
timini 7y ago
is there a colour scheme which respects this idea?
guywithahat 7y ago
That’s actually pretty clever, although I’d be concerned that you’d end up with too much of everything highlighted, making it hard to read again. But it’s a clever notion
jimmaswell 7y ago
What setups are you all using? To me I just associate comments with green, not fadedness. Only exception is Python has an unfortunate case of multiline strings having to be abused for multiline comments but maybe successive # lines would be better anyway, the way IDE's use multiple // instead of a /* */.
GnarfGnarf 7y ago
I'd like to go way beyond that: I'd like an editor that supports HTML in specially formatted comments, or better yet SVG, so I can embed comments in table format, diagrams, relationship flow charts, etc. Ideally the editor would allow me to modify the graphics. Being vector, they would check into version control. Also, I would like all function name definitions to be in bold, in a larger font.
- stelonix 7y ago
  Couldn't that, in principle, be implemented as an Atom plugin? You'd be able to get the HTML output you desire.
  - GnarfGnarf 7y ago
    Thanks for the tip. Hadn't heard of Atom, looks promising. I use Visual Studio to edit & compile, and Qt Creator. You've given me an idea: a VS plugin. Would a VS plugin be allowed to display the source code, I wonder? I'd pay money for that.
DenisM 7y ago
On a related note, I found that when rendering “Caption: Value” pairs like “Color: Red” I prefer the caption to be bold and value normal. Intuitively I wanted to do it the other way, but that never looked good in the end. Still puzzled.
blattimwind 7y ago
If you put a comment with "WARNING" or similar key words in it, some IDEs (JetBrains) will highlight the comment in bold and e.g. red.
jraph 7y ago
Kate highlights keywords like ATTENTION, WARNING, BUG, NOTICE and NOTE in comments. You can have your comments lighter than your code and still not miss important things.
kps 7y ago
> It sounds like the first IDE to bold keywords may have been MacPascal, which was written for a monochrome display. In that case it makes sense: with a monochrome display and one font, they could either make keywords bold or make everything else bold, and keywords was the less-intrusive option. MacPascal's bold keywords almost certainly descend from the Algol 60 report¹. ¹ http://www.softwarepreservation.org/projects/ALGOL/report/Algol60_report_CACM_1960_June.pdf/view http://www.softwarepreservation.org/projects/ALGOL/report/Al...
radium3d 7y ago
Honestly I prefer the code itself to stand out more as comments can be very bad but the code never lies.
jtolmar 7y ago
The typography tools that IDEs use for syntax highlighting are bold, italic, and color, which all reduce legibility. That's fine for keywords - I never need to distinguish between if and lf at a glance - but muddy for the primary content of your code (functions, variables, math symbols, comments). If you wanted to emphasize something while increasing legibility, you'd need to change the font size, which is not commonly supported by an IDE. Shrunken keywords might work. Not in conjunction with fixed width fonts, though.
blondin 7y ago
author has a very good point but the example is somewhat weak. if i recall correctly, pycharm knows about TODOs, WARNINGs, NOTEs, etc. not only it highlights these keywords but it also allows you to jump from one to the other throughout the code base. you can also customize how these are displayed. so no, out of the box WARNINGs are not an issue for pycharm. speaking of that, i need to check if vscode has a plugin for that (since everything is plugin driven in vscode...)
laughinghan 7y ago
I thought this was going to be about semantic coloring: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e https://medium.com/@evnbr/coding-in-color-3a6db2743a1e I think semantic coloring makes way more sense than this or syntax highlighting because it helps you see the actual flow of the code, unlike syntax highlighting which helps you see the syntactic structure of the code (should be second nature to any expert) and unlike this which merely helps you see comments (which even in the example in the blogpost is secondary information to what the code actually does, which is usually the main thing I want to know when I read code).
- maaaats 7y ago
  I tried rainbow/semantic coloring for a while, but felt it messed with my pattern recognizion. And when everything is highlighted, nothing is, it felt loud.
  - laughinghan 7y ago
    I totally get what you mean about loudness, I toned down the brightness (technically, saturation) of the colors in the palette I used once I started using semantic coloring. I don't know what you mean about "when everything is highlighted, nothing is"—shouldn't they be highlighted different colors, often diametrically opposed colors? With my coloring most of the time I don't even notice the semantic coloring except when I'm looking for it, especially when I type a long variable or method name and I'm thinking "did I spell this right?", if I see the same name somewhere else and if it has the same color, then I have high confidence I didn't make any typos.
    - pests 7y ago
      That usage reminds me of the now old visual password shape/color demos that let you know you typed your password correctly when it matches your expectations. I don't think it caught on anywhere though.
      - laughinghan 7y ago
drinchev 7y ago
First thing I usually change in a default syntax highlight theme is the color of the comments. I make them green, instead of gray. This makes my code ( IMHO ) much more readable. Also the comments ( when taken into consideration by the developer ) are one of the most important letters in the source code, so better be more visible than the keywords.
- galangalalgol 7y ago
  They are already green in visual studio. I always chamged my background to a slightly lighter green so I could easily ignore them. They lie.
IshKebab 7y ago
This is nonsense. His example only works because the comment is "WARNING: ...". Most comments are not like that, and the actual code is generally more important than the comments. Perhaps syntax highlighting should detect comments that say WARNING, like some detect TODOs. But that is a separate issue.
HighlandSpring 7y ago
How about this: taking all the user-named symbols in the tree (field names, method names, etc) and assigning them dissimilar colours? It becomes easy to see where the variable you're looking at is being used and if you have a typo the colour won't match.
- z3t4 7y ago
  There are not that many colors to choose from if you want good contrast.
itsmejeff 7y ago
“All these super smart people who came before me spent more collective time than my entire life, but the solution they arrived at is wrong “
bogomipz 7y ago
I'm curious are there any standard or well-known algorithms that are commonly used to implement syntax highlighting or does each implementation/IDE plugin tend to use something completely custom?
MrPatan 7y ago
I think there's two ways people look at code: as text to be linearly read, or as a structure to be navigated visually. I'm on the later camp, and I believe that's why I dislike the "movement" towards getting rid of puntctuation like (in JS land) semicolons, function braces and parens, and the like. That helps me parse the code visually into its structure, while it must just appear like noise to somebody "reading" code linearly. Now, for the kicker: Who do you think writes more blog posts about how much they like their languages and code highlighting, people in the "text thinking" camp, or the "visual thinking camp"?
wruza 7y ago
Syntax highlighting is not enough to stand out sections and blocks either way. Few good ideas do exist (like #pragma mark + dropdown, etc), but it would be nice to see that in more languages and in greater usability. #.h1 Auxiliary functions #.h2 Date routines function foo(x) { #.summary { // this foo does // no bar, baz } #.fold { assert(x != null) } } code-style.css: .summary > comment { font-size: 20px; color: red; } .fold { display: fold; } function-kw {...} function-name {...} .h1 { margin-top: 80px; } comment { margin-top: 5px; margin-left: 10px; border-left: 2px solid grey; } id[name=“assert”] { color: green; } That’s what cascades stylesheets were done for. Another advantage is that we could create color themes with css, not with some cryptic barely documented config. And then toggle read/edit/toc like your wiki page. We could write entire technical documents in it. Sadly, that’s not possible as current mainstream stuck in raw text. We have all formatting for pointless blah-blah, but no formatting for a thing that manages everything.
shrimpx 7y ago
You can easily highlight/make prominent comments based on occuring words in them like TODO, DEPRECATED, WARNING, etc., and some syntax highlighters do this out of the box. Making all comments bold is an overly broad approach to cover this case.
luord 7y ago
Other than my thinking that comments should be only for jokes, I like this idea. I'd leave the comments faded, and the keywords also faded, but probably in a different color.
barrkel 7y ago
I've always highlighted my comments in bold green. They've never been minimized or backgrounded.
blt 7y ago
it doesn't really matter what style you assign to each class of text - it only matters that they are different.
gcoda 7y ago
For a few month i am using minimal, black on white theme, some keywords are bold, strings a bit grayish, comments are bold and blue. When i opened a JSX file, i really wanted one more color, still considering.

274 points by pcr910303 7y ago

uxp 7y ago

Do I have some weird rendering issue with this website, or do both of these snippets of code have terrible readability and highlighting? If I had to write code using an IDE or editor with this scheme I'd quit my career and go into small engine repair. https://imgur.com/a/vS2EldV https://imgur.com/a/vS2EldV

saagarjha 7y ago
The text is black for me on my iPhone.
- FPGAhacker 7y ago
  It might be a dark mode thing. Edit: Yep, dark mode mangled the code snippets.
  - saagarjha 7y ago
    It is!
FPGAhacker 7y ago
That’s what it looked like for me. I thought maybe it looked illegible to me due to red-green color deficiency.
- FPGAhacker 7y ago
  It’s a dark mode thing. Looks normalish with dark mode off.
- jeltz 7y ago
  Nope, I am not color blind and it is very hard to read for me too.
jeltz 7y ago
Nope, it looks the same to me and I have a screen with high contrast and high brightness. Both his examples are very hard to read. And I have done color blindness tests and know I am not color blind. Another thing: I think one thing he is missing is how important it is to see at a glance where function definitions are and where possible early returns are. The first example highlights def (function definitions), return (possible early return) and the return type (arguably not that important in most cases).
SahAssar 7y ago
I think this is what it is supposed to look like: https://imgur.com/a/OHkBb8Q https://imgur.com/a/OHkBb8Q
pcr910303 7y ago
I'm pretty sure it's b.c. you have dark mode turned on & the CSS didn't consider code snippets. Try turning them off, it'll look much better.
- deleted 7y ago
  [deleted]
- jeltz 7y ago
  Thanks, it is better now but still not very good.
- Mathnerd314 7y ago
  ui.systemUsesDarkTheme = 0 for FF users.
  - mercora 7y ago
    I use "widget.content.gtk-theme-override;Adwaita:light" to fix commonly invalid assumptions about default colors and appearances. It overrides the GTK theme used to render page content and still allows to use a dark theme (or whatever you want) for UI components.
czr 7y ago
hack to switch to light mode, if you don't want to do it systemwide (paste into console): Array.from(document.styleSheets).forEach(ss => Array.from(ss.rules).forEach((ssr,i) => {if (ssr.cssText && ssr.cssText.includes("dark")) {ssr.parentStyleSheet.deleteRule(i)}}))
benkuhn 7y ago
Sorry about that! I built dark mode after writing this post and it broke the main text color inside the `pre`s, which should have been #222. Should be fixed now.

whalesalad 7y ago

I totally agree with the sentiment of the author but the execution is really terrible. I'm not sure how the end product is at all better. It's appearing as like #CCC or #EEE on a white background. Screenshot: https://s3.whalesalad.com/images/hn/syntax.png https://s3.whalesalad.com/images/hn/syntax.png My favorite color scheme for a long time has been Made of Code, which I have slowly tweaked over the years. It has particularly great rendering of comments, where the line of the comment has a background color that takes up the entire row. Example 1: https://s3.whalesalad.com/syntax/made-of-code-tweaked.png https://s3.whalesalad.com/syntax/made-of-code-tweaked.png Example 2: https://s3.whalesalad.com/syntax/made-of-code-tweaked-2.png https://s3.whalesalad.com/syntax/made-of-code-tweaked-2.png Theme file (Textmate/Sublime): https://s3.whalesalad.com/syntax/whalesalad-2.tmTheme https://s3.whalesalad.com/syntax/whalesalad-2.tmTheme

bastawhiz 7y ago
Try disabling dark mode on your device.
rozab 7y ago
That theme looks very good from a practical standpoint, there's a lot of nicely contrasting colours. Do you personally find it aesthetically appealing though? I don't really. For me aesthetics is a big factor. I've always liked having my computer set up the way I like. I don't have anything on my desk, so I think it's the equivalent of desk decorations. It makes me feel comfy and at home and thus more productive. My favourite theme right now is Hopscotch. [0] I also find the reduced contrast also makes it easier to look at for long periods. [0]: https://github.com/idleberg/Hopscotch https://github.com/idleberg/Hopscotch

Longhanks 7y ago

How is this gray on gray on black better than just coloring the method name differently? Seems to me the author just isn't happy with the color scheme, but discarding syntax highlighting alltogether seems like a step too far. Different colors definitely help me to quickly scan code.

kissgyorgy 7y ago

This is on par with what Uncle Bob said in an episode of Clean Code. He went as far as saying comments should be red!

beaconstudios 7y ago

this seems fundamentally similar to the idea of literate code, where the domain and context-specific information like comments (and in TFA, function and variable names) are put front and center. This approach makes more sense to me though, as literate programming emphasises writing a book that incidentally contains source code, whereas the idea of valuable comments nowadays is closer to highlighting concerns or explaining functionality that isn't evident or easy to read in the code itself. Or in other words; this sounds like a good idea! I wonder if it would help decrease the incidence of people ignoring and not updating comments though, as a developer's focus is often primarily on correcting the code and thus even with bolding the comments may end up falling into the same trap as banner blindness[1]. [1] https://en.wikipedia.org/wiki/Banner_blindness https://en.wikipedia.org/wiki/Banner_blindness

bastawhiz 7y ago

This largely seems like an issue with the author's IDE or theme, not an issue with syntax highlighting. I immediately assumed the first screenshot was what they were proposing since it's not like the syntax highlighting that I have used in vi, sublime, visual studio, or vscode. The actual proposal, to my eyes, removes highlighting entirely: I can't differentiate the shades well at all, and the "bold" commented text is even less visually distinct than in the original. Semi-related: do folks actually use very low contrast themes like the one in the screenshot? My vision is better than 20 20 and reading light gray on white (or dark gray on black, for that matter) is a terrible strain on my eyes. Edit: it appears the author has a dark mode theme on their blog which changes the colors of the screenshots

Mikeb85 7y ago
I personally like relatively low contrast colours on a dark background. High contrast themes put strain on my eyes.
squeaky-clean 7y ago
PyCharm is extremely configurable. I've probably spent a whole day or more setting up my preferred syntax highlighting and keybindings. I think the default highlighting is fine because it's what's best for beginners, highlighting language keywords and such.
csdvrx 7y ago
Yes, I use a low contrast theme, light grey on yellow. My vim is Solarized based so I can invert colors at night and get more contrast by collapsing the RGB values into just red using NegativeScreen. My bash is more custom: to be even lower contrast, I don't use colors except for when commands return with an error code. Instead, I use font attributes a lot (bold, italics, faint, etc) and I timestamp my commands so when I check my records I can easily find which parts took me the longest to think and do. The command I am typing has the current directory in bold to quickly remind me as I usually have several terminals opened. Here is what my bash (where I spend the most time in) and vi looks like: https://raw.githubusercontent.com/csdvrx/sixel-tmux/master/sixel-tmux.jpg https://raw.githubusercontent.com/csdvrx/sixel-tmux/master/s... My bash has changed to match vi: the # prompt and red error codes now use the background color with: \e[2;48;2;215;215;175m\]#[\e[0m\]

akkartik 7y ago

Not all comments are worth highlighting: http://akkartik.name/post/2012-11-24-18-10-36-soc http://akkartik.name/post/2012-11-24-18-10-36-soc For the last 6 years I use three colors for comments: https://i.imgur.com/vU783Xo_d.jpg?maxwidth=640&shape=thumb&fidelity=medium https://i.imgur.com/vU783Xo_d.jpg?maxwidth=640&shape=thumb&f... If you have a configurable editor you can find more useful things to highlight in the code as well: https://www.reddit.com/r/programming/comments/1w76um/comment/cezpios https://www.reddit.com/r/programming/comments/1w76um/comment...

saagarjha 7y ago
Your second image is really blurry :(
- akkartik 7y ago
  Yeah, fixed now.
  - empyrical 7y ago
    The _d in the imgur link renders it as a thumbnail, here's the full res version: https://i.imgur.com/vU783Xo.jpg https://i.imgur.com/vU783Xo.jpg
    - akkartik 7y ago
      Thank you! I actually started out with that link, but it rendered with all the usual Imgur cruft on my phone :/
SlowRobotAhead 7y ago
> It seems those who write sparse comments want them to pop out of the screen, and those who comment more heavily like to provide a background hum of human commentary that's useful to read in certain contexts and otherwise easy to filter out. This has slightly increased the number of comments overall and while I think quality has gone way up, I don’t want them more visible to the point of distraction. Yep. Put me in the latter camp. If you made my comments more visable it would be highly distracting. Thinking about it like commentary is good because along with WHY comments over WHAT comments, I’ve been making an effort to describe INTENT for future readers (me).

mjburgess 7y ago

The quality of the execution of the author's idea is a good guide to the quality of the idea itself. In general, comments are not so informative and the code is self-documenting. ie., the code itself should be emphasized for comprehension. The author misses the purpose of highlighting: to supply grammatical information where the language itself is deficient. Since we have plenty of experience with english grammar, we do not need help.

lgeorget 7y ago

As with a lot of things, this is ultimately a matter of personal preferences, and the compiler could not care less about how your code is displayed in your editor. So, the question is not whether is's "backwards" or not, it's only a matter a finding the highlighting theme that subjectively suits you. In my case, I prefer having the keywords highlighted and comments less visible than the code. Why? Because code is not something I read linearly. Having the syntactic markers highlighted helps me visually navigate from blocks to blocks. And it makes it much easier to spot missing curly braces, parentheses, etc.

jeltz 7y ago
Same preference here. I use highlighted keywords to navigate and find stuff quickly in files. Especially important is highlight of some keywords like "return" so I do not miss any early returns.
SlowRobotAhead 7y ago
This is a good counter argument to the article. I know instantly what a switch statement does, but if I have big bold markers for where a switch and it’s cases are, that helps me jump to the block I’m looking for. In the case of faint comments, I may need to slow down and actually read them if they’re a little less visible. I also know instantly that comments aren’t code and I don’t want all my code faint so just them being different from each other is enough for me. Article makes good points but doesn’t seem like it’s for me.
- dr_zoidberg 7y ago
  I've seen a few editors[0] highlight certain words in comments like "TODO", "BUG", "FIXME", etc. It depends on the parser that the higlighter uses (some regex based may have limitations here), but it does exist. [0] pycharm and vscode come to mind because I use them the most, but other that I don't recall also do it edit: a couple of typos
  - SPBS 7y ago
    Vim highlights those by default too. I had no idea that was a default in vscode as well

marktangotango 7y ago

I read this as the author advocating for some form of "comments first" development philosophy. As such, I'd like to submit this well known bit of work by Knuth for consideration (by anyone not already familiar with it): https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming IME that gives all a starting point or base line for discussions around "what can more/good/better comments and support for documentation do for me".

xwdv 7y ago

I used to put comments in a more faded out color because most aren’t worth reading and they certainly aren’t worth highlighting.

SlowRobotAhead 7y ago
If you are writing comments that aren’t worth reading, what is the point at all? WHY not WHAT really helped me out. WHY is this thing here instead of WHAT it is can give a line like i++; a vastly different comment and implication for the reader.
- xwdv 7y ago
  Comments can go rapidly out of date and rarely get updated properly to reflect new changes in code. As a result, comments lie and can’t be trusted, and the only source of truth is actual code.
  - nikisweeting 7y ago
    I've people on previous teams that thought this, and their comments were consistently the ones that were the most out-of-date because they never valued fixing them. If you value comment accuracy during PR reviews then you're less likely to end up in that situation in the first place.
    - throwaway40324 7y ago
      This. I totally agree. One fallacy I've seen is a reviewer only looking at the diff on Github, where a minor change in the middle of a function is made, and they don't expand the diff to notice that the new change completely invalidates a comment, params, call signature, return value..etc.

klodolph 7y ago

Maybe for internal comments. I like having different styles for docstring comments and other comments. /** Frobnicate the weevil with the given ID and return 0 on success. * * Locks the weevil during frobnication, which may take a while. */ int weevil_frobnicate(const char *id); The most important part here is the function definition and its types and parameters. Usually, when I'm looking for a function, the name and type is enough to find what I'm looking for. So I want the function declaration to stand out and the docstring to be faded.

twotwotwo 7y ago

The most intriguing version I've heard of this was also based on the feeling that it's already easy to scan for keywords and structure; they went a different direction, using color to make different things (especially confusable ones) look different: https://wordsandbuttons.online/lexical_differential_highlighting_instead_of_syntax_highlighting.html https://wordsandbuttons.online/lexical_differential_highligh... I don't feel like I know how/if highlighting helps, so all I can really say is seems interesting. I think some of the problems commenters are having with the color scheme are because the site has a dark mode and contrast might be worse when it's on. Maybe in that mode text colors meant for a dark background are still getting applied in the white-backgrounded code fragments.

dystroy 7y ago

We're really good at parsing code, thanks to languages designed to be easy to read and to our style guides (unless we don't have one, of course). Highlighting keywords is uselessly tiring for the eyes IMO. What matters most is to separate code from what's not code and which doesn't follow the same rules: comments and string-like literals. In my vim color scheme (https://github.com/Canop/patine https://github.com/Canop/patine) I only have three colors: one for code, one for comments, one for strings, and I find reading the code easier and less tiring this way.

z5h 7y ago
Yes yes yes! For a long time this three color style was my philosophy. It's all you need. I'm currently (with new laptop) doing a thing where I try to install/customize as little as possible. This means not using that philosophy, but not because it didn't work.
mikelward 7y ago
Me too. Plus a color for errors, and one for line numbers and other non-code parts of the UI. https://github.com/mikelward/conf/blob/master/vim/colors/basic.vim https://github.com/mikelward/conf/blob/master/vim/colors/bas... And a similar theme I wrote for vscode. https://marketplace.visualstudio.com/items?itemName=mikelward.theme-plainlight https://marketplace.visualstudio.com/items?itemName=mikelwar...

gorgoiler 7y ago

It’s definitely subjective. For me, I see highlighted keywords as the anchors around which the creative process occurs.

jbverschoor 7y ago

In eclipse comments such as TODO and FIXME were always bold. The thing with important comments is that they are verbose, so they can span for example 5 lines (or 3 in this example). Because of this, they already have more attention. I think most themes are pretty sane. There's a mixture of blue, darkblue and black for keywords and methods/vars. For contrast, strings and numbers are red and green. Comments are green, so they stand out enough for me.

smnrchrds 7y ago

This is certainly true for learnxinyminutes.com The comments are the most important part of the document, yet they are barely visible due to colour and contrast chosen by syntax highlighter. Example: https://learnxinyminutes.com/docs/csharp/ https://learnxinyminutes.com/docs/csharp/

clatan 7y ago

Yeah... No thank you. I mostly look at/work in code

foobar_ 7y ago

I've been using nosyntax for a while ... this seems like an good addition to that.

czr 7y ago

for those interested, there's a longer discussion of this idea at https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/ https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... (2014)

franciscop 7y ago

I totally agree, made a while ago a snippet for Atom with syntax highlighting based on a similar article [1] that will make comments bright pink (meta-tweet with the code in effect): https://twitter.com/FPresencia/status/1133733608785473536 https://twitter.com/FPresencia/status/1133733608785473536 For copy/paste (in Atom -> Stylesheet...): .syntax--comment, .syntax--punctuation.syntax--definition.syntax--comment, .syntax--comment .syntax--markup.syntax--link { color: rgba(255, 51, 255, 0.8); } .syntax--comment.syntax--block, .syntax--comment.syntax--line { background: rgba(255, 51, 255, 0.1); } [1] https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/ https://jameshfisher.com/2014/05/11/your-syntax-highlighter-...

PretzelFisch 7y ago
It doesn't look like you completely agree, you kept the code blocks readable rather then flipping their styles like the author.

tengbretson 7y ago

This sounds nice in an idealistic situation where comments are limited to identifying important gotchas, but in my experience there's way too many bullshit comments in most software

buboard 7y ago

Highlighting is meant to create "visual handles" on the code so your eyes can quickly jump to beginning/end of function/loop to figure out the scope of the comment. If you put the comment first , it's like replacing the floor numbers in an elevator with the warning signs. At most , you'd highlight just the word "WARNING:" or "TODO:" etc. Anything more is clutter

PretzelFisch 7y ago

The trouble is with the propagation of poor template systems auto generating relevant comments and new/junior developers writing comments that are just what the code does as opposed to functionally important. Since this represents the bulk of comments most themes have started to contrast them out so that the actual code is more prominent But to fix this the author should just find a better contrast for comments in their chosen theme so they are just as readable as code. The idea you would make comments more prominent and the code harder to read leads me to believe they don't write much code.

TeMPOraL 7y ago

Personally, I tweaked the default syntax coloring to deemphasise only punctuation (e.g. parentheses), and emphasise comments (for the reason outlined in the article). I don't think it's necessarily a good idea to deemphasize keywords - they often imply change in the evaluation semantics, so it's good to be able to spot them easily when scanning.

mdip 7y ago

I came to the conclusion about comments about a year ago for a completely different reason ... though, ultimately, ended up saving me in the way he mentioned: In my IDE, comments are bolded, italicized and red with a dashed underline and a mark on the scrollbar (thanks Rider). It's extreme, but it works perfectly with my code and commenting style. Doc comments are not treated this way, only inline comments, of which you may find one or two in an entire project of mine. I did away with non-doc comments a long while ago, and originally set this style in order to have any I'd missed stand out and "be ugly" so that I'd move the comments into a "remarks" section of the doc comments. The side-effect, though, is that when I'd run into a comment that was a "here be dragons", it'd stand out so strongly that you couldn't miss the warning. So I left it that way for good.

benkuhn 7y ago

Sorry to everyone who complained about the colors! I added a dark mode recently and it broke the custom CSS in this post. I've fixed it now. (Well, you may still not believe it's fixed :P )

zedgerman 7y ago

SourceInsight[1] always had an interesting perspective on this. It seems popular with the low-level C++ crowd in particular. [1] https://www.sourceinsight.com/doc/v4/userguide/index.html#t=Manual%2FConcepts%2FSyntax_Formatting_and_Styles.htm https://www.sourceinsight.com/doc/v4/userguide/index.html#t=...

pixelmonkey 7y ago

I've watched a lot of talks on Python by @dabeaz (David Beazley) and attended a couple of his in-person courses in Chicago. I was always amazed about the fact that he used emacs with no syntax highlighting, no line numbers, etc. as his live coding buffer. When I asked him about it one time, his answer really made me think hard about my own "souped up" vim setup. He said, "The hard part of coding in Python isn't getting the syntax right; the hard part is getting the logic right. Syntax highlighting makes me focus on the syntax when I should be focusing on the logic." I didn't change my own setup, but it did get me to question my default assumptions on the practice. That said, one specific example when syntax highlighting is very useful IMO is "rainbow parentheses". Especially when coding in Scheme, Racket, Lisp, Clojure, etc. But also for matching parens in fluent APIs and for matching braces in JSON.

gav 7y ago
I spent a long time without syntax highlighting, or very minor highlighting (parenthesis/brackets/braces) but at a conference somebody told me that looking at monochrome text all day was depressing and that adding color with syntax highlighting made things less gloomy. Since then I've liked adding a little color.
- pixelmonkey 7y ago
  The aesthetic feeling of a nicely colored buffer is the reason I keep my syntax highlighting around! It just feels nice.
CmdrKrool 7y ago
A counter response to Beazley's quote might be, "syntax highlighting helps the syntax get out of the way so that I can focus on the logic". I suppose that's exactly what's happening in your "rainbow parentheses" case when you have way better things to do than squinting to count those little bleeders.

astrobe_ 7y ago

And one could say it is also inside-out: https://en.wikipedia.org/wiki/ColorForth https://en.wikipedia.org/wiki/ColorForth Basically in ColorForth, color is sort of part of the syntax. For instance when you want to define a new function, you would use the red color to type its name.

BurningFrog 7y ago

I mostly disagree. If your codebase have good, sparse and accurate comments this could make sense. But I don't see a lot of that. It's mostly low quality and outdated. I want to see the code, because that's what's actually being executed.

a-nikolaev 7y ago

I have this color scheme for Vim with keywords greyed, in favor of other parts of the program syntax that look brighter in comparison: https://github.com/a-nikolaev/vim-boltzmann https://github.com/a-nikolaev/vim-boltzmann - keywords are grey - comments are red - constant and literals are green and blue - main text is off-white Keywords often can be guessed from the overall structure of the program block and its indentation, especially in languages like OCaml. So making them bright only adds noise, distracting from what's important.

m4r35n357 7y ago

Yep, everybody's got one.

beaker52 7y ago

Drawing attention to language constructs like if and return helps you visually identify patterns. When you need to know details you look into the specific code. Highlighting the noisiest and least uniform parts of code is probably not what I really want. I don't want to draw references from an entire book in title case, with tiny section and chapter titles for example. Highlighting helps me identify code from a distance, it doesn't help me read it. It's about visual cues that eventually form into heuristics that save me time as I roam around a codebase. "Oh this is one of those" "that's not the kind of function that I'm looking for"

michaelcampbell 7y ago
Yup, highlighting is for code shape, not content.
chadlavi 7y ago
This. I really couldn't disagree more with the linked article on this.

creatonez 7y ago

Of note is that Kate editor, when used with a language server, has an interesting approach to syntax highlighting. It has something called rainbow highlighting, which colors each variable/class/whatever uniquely.

jobigoud 7y ago
Interesting! Are the keywords also having their own color each, or are they grouped in a single color?
recursivecaveat 7y ago
I have also heard this called 'semantic highlighting' for anyone searching for a plugin for their editor. Not sure if any do this, but it would be interesting to try a version that assigns bands of colours to different types of symbols. Eg earthy colours for parameters, neon for locals, pastels for globals, etc.
- nikisweeting 7y ago
  There's a plugin that does semantic highlighting for Sublime, then Sublime added native support for it a little while ago. Since then I haven't seen any new plugins that take advantage of the new native Sublime functionality though.
squeaky-clean 7y ago
You can enable this in PyCharm too (the IDE from the post) and probably every other IntelliJ variant. I believe it takes a hash of the variable name and turns it into a color? Because it will consistently keep color for the same tokens across projects and files. Really useful! Though maybe I installed a plugin to do this, I'm away from ny laptop at the moment (happy holidays).

powerapple 7y ago

I had the same thought a few years back. I think it depends on are you 'reading' code or 'writing' code. When reading code, I want to read comments rather than ignoring them. When writing code, syntax highlighting is kind of doing spell checks for you. I don't think they are really useful, but you can't go back once you have them.

hzhou321 7y ago

It is not backward. The keywords to a program are like skeletons to a body and highways to a city. While we agree that the organs or even muscles are more meaningful to a body's function and the business inside buildings off the road are the essence of a city, skeletons and roads provide structures and makes it possible for those "meanings" to render. Without it, one can't practically dive into the more complex and meaningful stuff without getting lost. While the keywords are not the real meaningful part of code, it contributes the most to organize and to manage the complexity of code. So functionally, in terms of managing code and making writing and reading sophisticated programs possible, keywords are the most important parts.

laurent123456 7y ago

(2018)

dang 7y ago
Added. Thanks!

timini 7y ago

is there a colour scheme which respects this idea?

guywithahat 7y ago

That’s actually pretty clever, although I’d be concerned that you’d end up with too much of everything highlighted, making it hard to read again. But it’s a clever notion

jimmaswell 7y ago

What setups are you all using? To me I just associate comments with green, not fadedness. Only exception is Python has an unfortunate case of multiline strings having to be abused for multiline comments but maybe successive # lines would be better anyway, the way IDE's use multiple // instead of a /* */.

GnarfGnarf 7y ago

I'd like to go way beyond that: I'd like an editor that supports HTML in specially formatted comments, or better yet SVG, so I can embed comments in table format, diagrams, relationship flow charts, etc. Ideally the editor would allow me to modify the graphics. Being vector, they would check into version control. Also, I would like all function name definitions to be in bold, in a larger font.

stelonix 7y ago
Couldn't that, in principle, be implemented as an Atom plugin? You'd be able to get the HTML output you desire.
- GnarfGnarf 7y ago
  Thanks for the tip. Hadn't heard of Atom, looks promising. I use Visual Studio to edit & compile, and Qt Creator. You've given me an idea: a VS plugin. Would a VS plugin be allowed to display the source code, I wonder? I'd pay money for that.

DenisM 7y ago

On a related note, I found that when rendering “Caption: Value” pairs like “Color: Red” I prefer the caption to be bold and value normal. Intuitively I wanted to do it the other way, but that never looked good in the end. Still puzzled.

blattimwind 7y ago

If you put a comment with "WARNING" or similar key words in it, some IDEs (JetBrains) will highlight the comment in bold and e.g. red.

jraph 7y ago

Kate highlights keywords like ATTENTION, WARNING, BUG, NOTICE and NOTE in comments. You can have your comments lighter than your code and still not miss important things.

kps 7y ago

> It sounds like the first IDE to bold keywords may have been MacPascal, which was written for a monochrome display. In that case it makes sense: with a monochrome display and one font, they could either make keywords bold or make everything else bold, and keywords was the less-intrusive option. MacPascal's bold keywords almost certainly descend from the Algol 60 report¹. ¹ http://www.softwarepreservation.org/projects/ALGOL/report/Algol60_report_CACM_1960_June.pdf/view http://www.softwarepreservation.org/projects/ALGOL/report/Al...

radium3d 7y ago

Honestly I prefer the code itself to stand out more as comments can be very bad but the code never lies.

jtolmar 7y ago

The typography tools that IDEs use for syntax highlighting are bold, italic, and color, which all reduce legibility. That's fine for keywords - I never need to distinguish between if and lf at a glance - but muddy for the primary content of your code (functions, variables, math symbols, comments). If you wanted to emphasize something while increasing legibility, you'd need to change the font size, which is not commonly supported by an IDE. Shrunken keywords might work. Not in conjunction with fixed width fonts, though.

blondin 7y ago

author has a very good point but the example is somewhat weak. if i recall correctly, pycharm knows about TODOs, WARNINGs, NOTEs, etc. not only it highlights these keywords but it also allows you to jump from one to the other throughout the code base. you can also customize how these are displayed. so no, out of the box WARNINGs are not an issue for pycharm. speaking of that, i need to check if vscode has a plugin for that (since everything is plugin driven in vscode...)

laughinghan 7y ago

I thought this was going to be about semantic coloring: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e https://medium.com/@evnbr/coding-in-color-3a6db2743a1e I think semantic coloring makes way more sense than this or syntax highlighting because it helps you see the actual flow of the code, unlike syntax highlighting which helps you see the syntactic structure of the code (should be second nature to any expert) and unlike this which merely helps you see comments (which even in the example in the blogpost is secondary information to what the code actually does, which is usually the main thing I want to know when I read code).

maaaats 7y ago
I tried rainbow/semantic coloring for a while, but felt it messed with my pattern recognizion. And when everything is highlighted, nothing is, it felt loud.
- laughinghan 7y ago
  I totally get what you mean about loudness, I toned down the brightness (technically, saturation) of the colors in the palette I used once I started using semantic coloring. I don't know what you mean about "when everything is highlighted, nothing is"—shouldn't they be highlighted different colors, often diametrically opposed colors? With my coloring most of the time I don't even notice the semantic coloring except when I'm looking for it, especially when I type a long variable or method name and I'm thinking "did I spell this right?", if I see the same name somewhere else and if it has the same color, then I have high confidence I didn't make any typos.
  - pests 7y ago
    That usage reminds me of the now old visual password shape/color demos that let you know you typed your password correctly when it matches your expectations. I don't think it caught on anywhere though.
    - laughinghan 7y ago

drinchev 7y ago

First thing I usually change in a default syntax highlight theme is the color of the comments. I make them green, instead of gray. This makes my code ( IMHO ) much more readable. Also the comments ( when taken into consideration by the developer ) are one of the most important letters in the source code, so better be more visible than the keywords.

galangalalgol 7y ago
They are already green in visual studio. I always chamged my background to a slightly lighter green so I could easily ignore them. They lie.

IshKebab 7y ago

This is nonsense. His example only works because the comment is "WARNING: ...". Most comments are not like that, and the actual code is generally more important than the comments. Perhaps syntax highlighting should detect comments that say WARNING, like some detect TODOs. But that is a separate issue.

HighlandSpring 7y ago

How about this: taking all the user-named symbols in the tree (field names, method names, etc) and assigning them dissimilar colours? It becomes easy to see where the variable you're looking at is being used and if you have a typo the colour won't match.

z3t4 7y ago
There are not that many colors to choose from if you want good contrast.

itsmejeff 7y ago

“All these super smart people who came before me spent more collective time than my entire life, but the solution they arrived at is wrong “

bogomipz 7y ago

I'm curious are there any standard or well-known algorithms that are commonly used to implement syntax highlighting or does each implementation/IDE plugin tend to use something completely custom?

MrPatan 7y ago

I think there's two ways people look at code: as text to be linearly read, or as a structure to be navigated visually. I'm on the later camp, and I believe that's why I dislike the "movement" towards getting rid of puntctuation like (in JS land) semicolons, function braces and parens, and the like. That helps me parse the code visually into its structure, while it must just appear like noise to somebody "reading" code linearly. Now, for the kicker: Who do you think writes more blog posts about how much they like their languages and code highlighting, people in the "text thinking" camp, or the "visual thinking camp"?

wruza 7y ago

Syntax highlighting is not enough to stand out sections and blocks either way. Few good ideas do exist (like #pragma mark + dropdown, etc), but it would be nice to see that in more languages and in greater usability. #.h1 Auxiliary functions #.h2 Date routines function foo(x) { #.summary { // this foo does // no bar, baz } #.fold { assert(x != null) } } code-style.css: .summary > comment { font-size: 20px; color: red; } .fold { display: fold; } function-kw {...} function-name {...} .h1 { margin-top: 80px; } comment { margin-top: 5px; margin-left: 10px; border-left: 2px solid grey; } id[name=“assert”] { color: green; } That’s what cascades stylesheets were done for. Another advantage is that we could create color themes with css, not with some cryptic barely documented config. And then toggle read/edit/toc like your wiki page. We could write entire technical documents in it. Sadly, that’s not possible as current mainstream stuck in raw text. We have all formatting for pointless blah-blah, but no formatting for a thing that manages everything.

shrimpx 7y ago

You can easily highlight/make prominent comments based on occuring words in them like TODO, DEPRECATED, WARNING, etc., and some syntax highlighters do this out of the box. Making all comments bold is an overly broad approach to cover this case.

luord 7y ago

Other than my thinking that comments should be only for jokes, I like this idea. I'd leave the comments faded, and the keywords also faded, but probably in a different color.

barrkel 7y ago

I've always highlighted my comments in bold green. They've never been minimized or backgrounded.

blt 7y ago

it doesn't really matter what style you assign to each class of text - it only matters that they are different.

gcoda 7y ago

For a few month i am using minimal, black on white theme, some keywords are bold, strings a bit grayish, comments are bold and blue. When i opened a JSX file, i really wanted one more color, still considering.