Syntax Highlighting Off • Hacker News Board

Re: Syntax Highlighting Off

#61

Post by majewsky » Sun, Mar 13, 2016, 4:48 PM UTC

watchdogtimer wrote: post #50

adrianN wrote: post #3

Next step: programming using ed. But jokes aside, use whatever environment you like best. For me syntax highlighting is extremely useful. Knowing whether some strings of characters is a type or a variable, or a class type or a basic type makes programming just that much easier. It also helps catching simple typos if something doesn't have the color you'd expect.

A step up from ed but a step below vim is nvi. I've always preferred nvi over vim because: 1) there's no lag when I scroll up or down through a file line-by-line, 2) it shows a list of matching files by default when using tab completion in command mode (same as bash), vs picking the first matching filename, and 3) it uses fewer resources when you screw up ( http://galexander.org/vim_sucks.html ) I used to think that…

Re 2)

  set wildmode=list:longest

EDIT: Re 3), there's something weird going on.

I just tried the benchmark from the article that you linked ("1000000aaeou"), and it really did not complete in a useful timeframe. However, when I insert the text once, yank it, then paste it with repeat ("iaeou^y4l1000000p"), the operation completes instantly, and I can still browse the file without any slowdown. Undo/redo across this operation seems to take some seconds, though.

Re: Syntax Highlighting Off

#62

Post by jstimpfle » Sun, Mar 13, 2016, 4:49 PM UTC

richard_todd wrote: post #46

I have had syntax highlighting off for a few years, but I always turn it on when looking at XML... especially poorly formatted files. It helps my eyes navigate the soup. That's where I think the value is: it helps to make up for confusing formatting.

  nmap  :if exists("syntax_on") \| syntax off \| else \| syntax on \| endif \|
  nmap  :set wrap! wrap?

My personal productivity boost :)

Re: Syntax Highlighting Off

#63

Post by mchahn » Sun, Mar 13, 2016, 4:52 PM UTC

johansch wrote: post #2

"Reading code is simply more straightforward, smoother and less jumpy. I get the overarching context faster and with less hassle." This makes me think the author might be one of those people who can not superficially scan text very efficiently and resort to.. well, just reading it, word by word. (Is there a term for this phenomenon?)

I have several modes of reading code, from scanning very fast to find a section (highlighting helps a lot), to reading at medium speed for obtaining overall gist (highlighting good?), to slowly reading for accuracy (highlighting not needed).

It would be a pain to turn highlighting on/off since I switch modes rapidly and often. But I can image a mode where it changes highlighting based on scrolling speed. It would be easy fade the CSS colors to/from B/W on the fly.

Re: Syntax Highlighting Off

#64

Post by bluedino » Sun, Mar 13, 2016, 4:52 PM UTC

percept wrote: post #49

Purely eye candy here--visual enjoyment that makes code seem more interesting and fun. Did anybody else go from needing a white background, to preferring a dark one? (I had the zebra effect for years when trying to read light-on-dark, then one year something changed--I don't know exactly what.)

>> Did anybody else go from needing a white background, to preferring a dark one?

A white background was never preferable to me. So dang bright.

I started on with gray on black (BASICA) and yellow on black (Turbo Pascal 2.0). Later on things like Q-BASIC used gray on blue (which I would occasionally change to green on black), and the Borland IDE's continued with a blue background, but added syntax highlighting.

When I made the move to Windows and Visual C++, back we went to white backgrounds. Yikes. Xcode does this as well by default.

Re: Syntax Highlighting Off

#65

Post by mchahn » Sun, Mar 13, 2016, 4:54 PM UTC

Cthulhu_ wrote: post #15

Pirate-of-SV wrote: post #4

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.

> Low contrast / dimmed comments are basically saying "I spent time writing this, but it's not important, disregard".

One could make the opposite argument that comments are the important part and you only need to read code when diving in. This would be sort of a literate coding. I'm torn between making comments dimmer or brighter.

Re: Syntax Highlighting Off

#66

Post by marcosdumay » Sun, Mar 13, 2016, 4:59 PM UTC

adrianN wrote: post #3

Next step: programming using ed. But jokes aside, use whatever environment you like best. For me syntax highlighting is extremely useful. Knowing whether some strings of characters is a type or a variable, or a class type or a basic type makes programming just that much easier. It also helps catching simple typos if something doesn't have the color you'd expect.

Well, not ed, but refactoring Haskell code with sed incredibly nice.

Re: Syntax Highlighting Off

#67

Post by cxa » Sun, Mar 13, 2016, 5:16 PM UTC

_ph_ wrote: post #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 fr…

I've found an agreeable middle ground, which is to keep syntax highlighting on but to use a monochrome theme, where different types of tokens (like you mention) are distinguished by contrast instead of color. However, I don't personally favor pure blacks or whites (just ask any master printer).

I do make exceptions. For example, I color my cursor, as well as highlight matching parens if the cursor is on one of the pair (changing just the foreground color of the paren, not inverting it). The only color I use is red.

I don't make any objective claims that this is better, my aim is to make something "done well and tasteful", as you say.

Re: Syntax Highlighting Off

#68

Post by crdoconnor » Sun, Mar 13, 2016, 5:24 PM UTC

scottLobster wrote: post #42

philbo wrote: post #32

This post misses, for me, the greatest benefit of programming without syntax highlighting enabled. I went through a period of doing it for 5 years or so and the biggest effect was ultimately on how I wrote code, not how I read it. Without syntax highlighting I gradually became more focused on the legibility of what I was writing, because none of the visual cues were there when I read stuff back. Function length, modu…

I'm glad you had a positive experience, but I'd like to point out that thinking about legibility, whitespace, naming etc should be done regardless of highlighting. I don't blame you, IMO it's one of the major issues with computer science education. Even basic principles of clean code are often neglected or never taught, in large part due to the lack of professional experience in academic circles. This leaves aspiring…

>Even basic principles of clean code are often neglected or never taught, in large part due to the lack of professional experience in academic circles.

There's a lack of experience in professional circles too.

One of the questions I always ask during programming interviews (on either side) is "is your code clean? if so, why?". Invariably the answer is a variant along the lines of "if it passes the linter it's clean", which is stupid.

I'd like to say that's an automatic fail or automatic "don't work at this company" but it's just far too common.

Re: Syntax Highlighting Off

#69

Post by pklausler » Sun, Mar 13, 2016, 5:33 PM UTC

I've found that I really appreciate my editor's (aoeui) use of blue and black foreground colors for matching up parentheses and other brackets. Keyword highlighting is less useful apart from being a cue for correct spelling.

Re: Syntax Highlighting Off

#70

Post by barrkel » Sun, Mar 13, 2016, 5:36 PM UTC

pmoriarty wrote: post #43

barrkel wrote: post #24

I'd freely speculate that 90% of the benefit of syntax highlighting comes from mere lexical highlighting - specifically, making comments, strings and keywords visually distinct from everything else. And even keyword highlighting is very secondary to the first two. Making comments distinct from normal code is nice because you can easily alternate your focus on one or the other while reading through; and you're not lik…

One of the most important benefits of syntax highlighting that no one in this thread seems to be discussing is the highlighting of syntax errors. That is the number one benefit of syntax highlighting for me. It immediately shows me where there's a problem in my code (like if I haven't closed parenthesis or quotes) and keeps me focused on "completing the thought", as it were. This is also a reason that I don't like us…

Highlighting of errors is, for me, something distinct; a background parse / compile process that reports line numbers is sufficient. It doesn't need deep integration with the editor. A keyboard shortcut to go to the next error and you're pretty much all set.

I'm also not a big fan of overly eager syntax checking because I tend to compose abstractions on the fly, leaving a statement incomplete while I flesh out a dependency, or vice versa. Syntax aware indenting usually breaks badly in this situation - I generally prefer dumb indenting, with an opt-in block or file format option for where I want to fix code over a large area. I've had big fights with Emacs over this; it almost always does the wrong thing by default, whether it's indent location, continuation indent, mixing tabs and spaces in the indent, etc. About half my .emacs is replacement indentation functionality and configuration per mode.

I also don't like auto-completing parentheses, because it puts text ahead of the cursor on the current line. That's a PITA because the editor almost invariably doesn't know when I want to complete the expression or how. Eclipse is the worst at this (it's actually not possible to turn off in a sane way). It interprets RET as completing the expression when I want a line break inside the parens, and I'm constantly having to go back and forth to work around its mistakes.