Live data from Hacker News

Syntax Highlighting Off

robertmelton.com

11–20 of 110 posts

Re: Syntax Highlighting Off

#11

Many color schemes take the most important parts and fade them out: comments! In Haskell I have different colors for the comments, keywords, and literals. That's it. Anything more is not helpful. It's baffling to me to look at source on Github and see a screen full of comments, greyed out.

Comments are like footnotes in a book: great for adding context to the main text, but they work really well when shoved off to the side somewhere, easily accessible to those who want them, easily ignored by those just into the main text (e.g. Author). Unfortunately, code typography is so horrible in our field that we lack the ability to use the bottom page margin or a side bar for this purpose, so we hack it up with what's easy: syntax highlighting.

Re: Syntax Highlighting Off

#12

Many syntax highlight themes seem to hide comments in code by decreasing their contrast. I'm strongly against that so for me the author lost credibility when I saw that's more or less only what his theme do.

Comments lie, frequently. The only time I need to look a comments is when someone has done a poor job of naming things. The comments may explain intent, but they do not explain what it's doing.

Never question someone's credibility because their preference differs from yours. It'll make people question your credibility.

Re: Syntax Highlighting Off

#13
I started programming a long time ago, without any syntax highlighting at all, and the first time I tried it I found that all the different colours were more distracting than without, so count me as another for whom it's always remained off.

On the subject of unusual programming preferences, perhaps antialiasing off would be the next one the author could try. For me completely off is most comfortable, regular grayscale antialiasing is just bearable, and subpixel (like what's shown in his screenshots) just makes me feel dizzy after a short time.

Re: Syntax Highlighting Off

#15

Many syntax highlight themes seem to hide comments in code by decreasing their contrast. I'm strongly against that so for me the author lost credibility when I saw that's more or less only what his theme do.

I've wondered about that too. Low contrast / dimmed comments are basically saying "I spent time writing this, but it's not important, disregard". I'm sure it's part of the reason why comments are often not updated - they just don't stand out / draw attention to themselves.

Of course, legible code is more important in most cases.

Re: Syntax Highlighting Off

#16
I've always wanted to try this.

I started programming in 7th grade by randomly typing commands into my TI-83 during algebra class. I had no syntax highlighting, auto-complete, or even a choice of font, but I would sit there for _hours_ meticulously making lines jump around the screen.

Now I get stressed out when my color scheme isn't perfect.

Re: Syntax Highlighting Off

#17
I use syntax highlighting, but I prefer it to be quite minimalist. I use bold for keywords and different colors for string literals and comments. Also I use underscore for object fields. Modern IDEs usually configured with a lot of visual noise and it might make it harder to read, but probably it depends on person.

Re: Syntax Highlighting Off

#18
Syntax highlighting can help structuring your source code when done well and tastefully - coloring your source in all bright colors of the rainbow rather achieves the opposite effect.

Personally I am working with a white background, so I try to keep the syntax colors all very dark, so while the different colors can be seen, they should not distract from reading. The correct amount of highlighting very much depends from the language at hand, but it can be very helpful in separating elements, just as an example take this function parameter list:

func foo(name, family string, age, size int) {

The correct reading of this parameter list entirely depends on the placement of the commas and the knowledge that "string" and "int" are parameter types - highlighting the type elements can help a lot.

With the availability of high-dpi displays, perhaps colors should be replaced with more traditional ways of markup as used in book-printing, replace coloring with different typesets and fonts.

Re: Syntax Highlighting Off

#19

Many color schemes take the most important parts and fade them out: comments! In Haskell I have different colors for the comments, keywords, and literals. That's it. Anything more is not helpful. It's baffling to me to look at source on Github and see a screen full of comments, greyed out.

Comments are like footnotes in a book: great for adding context to the main text, but they work really well when shoved off to the side somewhere, easily accessible to those who want them, easily ignored by those just into the main text (e.g. Author). Unfortunately, code typography is so horrible in our field that we lack the ability to use the bottom page margin or a side bar for this purpose, so we hack it up with…

Comments also lie.

At best, they are a statement that, at the time they were last edited, the author believed their stated facts were true, or might become so, plenty are aspirational, "this is what this function or change to it, which I've not yet written, will do".

He might have been wrong, or the code might have changed without updating the comment, the actual running code is the only truth.

Re: Syntax Highlighting Off

#20
post #19

Earlier quoted context omitted.

Comments are like footnotes in a book: great for adding context to the main text, but they work really well when shoved off to the side somewhere, easily accessible to those who want them, easily ignored by those just into the main text (e.g. Author). Unfortunately, code typography is so horrible in our field that we lack the ability to use the bottom page margin or a side bar for this purpose, so we hack it up with…

Comments also lie. At best, they are a statement that, at the time they were last edited, the author believed their stated facts were true, or might become so, plenty are aspirational, "this is what this function or change to it, which I've not yet written, will do". He might have been wrong, or the code might have changed without updating the comment, the actual running code is the only truth .

To some degree I agree, but even if they don't lie they can still get in the way of code reading given the current sad state of code typography. If comments were handled better, I bet they would be updated more regularly with code changes since it would be more of an eye sore if they weren't.
Post reply on HN