
Turning off syntax highlighting - dudzik
http://dudzik.co/digress-into-development/syntax-off
======
jakub_g
Slightly meta: Turning off the syntax highlighting entirely seems a bit
hardcore to me, however, _I always read each commit I do_ via git diff / pull
request view, which does not have syntax highlighting (other than red/green
for removals/additions), and I always strive to make the diff look good for
each commit (which means, doing one thing at a time in each commit, and making
sure it reads well).

Unfortunately, not everyone I work with reads their code (yep, they write-
commit-push-and-forget!) which sometimes makes code review a not so nice
experience.

Please, please, _read your diffs_ before sending code for review.

~~~
DSMan195276
I agree completely. On that note, I also consider `git add -A` to be horrible
practice. Adding files manually makes you tons more aware of what changes you
actually made, and also prevents you from accidentally adding extra files you
don't want.

I also recommend people to look at the Linux kernel git history for good
examples of how to use git well. Even if you have no knowledge of kernel code
(and most people don't) it's still extremely clear how each commit makes a
single change and is fairly easy to review. Now, the Linux kernel has the
luxury of being able to demand people fix their commits, but that's not to say
you shouldn't strive to reach similar states in your commits.

~~~
iLoch
I just don't understand why people use the git CLI. Git is too powerful a
tool, using the CLI limits one of two things: your capabilities, or your
productivity.

Often times I see my coworkers screwing around with git trying to review diffs
and commit their changes. One of two things happens: they spend longer than
they should doing it, or they do it haphazardly. Sometimes they get it wrong.

Just use a GUI.

I use SourceTree and often find myself committing individual lines or chunks
in my files instead of the whole file. I'm confident the average git CLI user
doesn't even know this is possible. I can do massively complicated commits
with ease because I can see every single line that has changed right in front
of me.

I just don't understand the fetishization of source control via CLI. In all
likelihood it doesn't make you more productive, and it's probably less
accurate unless you really know you way around git.

~~~
craigds
As a counterpoint, every time I've tried a git GUI (I've tried lots), I end up
bashing my head against it within a few minutes. They usually make very basic
things easy and anything even _slightly_ outside the box basically impossible.

I'm much more productive using a couple of git commands that I can type in a
few seconds, rather than hunting for things in menus and dialogs for ages.

> committing individual lines or chunks in my files instead of the whole file

That's really git 101. I'd expect if you haven't learned to do that via the
CLI then maybe you gave up too soon and jumped straight to GUI? `git add -p .`
is very easy to use.

~~~
duerrp
did you try magit?

Maybe it is of limited use for non-emacs users, but imho it's a fantastic way
to use git with a perfect balance between making simple things very easy to do
and allowing (almost) anything you can do with the CLI while providing
excellent visual feedback.

~~~
btschaegg
I also found the git plugin [1] in the Sublime Text Package Control repository
to be rather useful. The basic idea is similar to magit, with the (subjective)
upside of avoiding the crazy Emacs hotkeys.

That said, since I discovered Spacemacs, I'm also enjoying using Magit - the
"evil" control scheme for it is great, too.

[1]:
[https://packagecontrol.io/packages/Git](https://packagecontrol.io/packages/Git)

------
bluejekyll
In the first few sentences he expressly states why you want highlighting:

> I couldn’t skip through the source that fast anymore and it became harder to
> read

Which, yes all the modifications to style (which is only his own code by the
way) helped factor out. But I bet he'd be even better now with highlighting
that he's made these additional changes to his style.

I worked for years without syntax highlighting. I am much more efficient with
it for exactly the reason quoted. To each their own, but having visual cues to
help is not a bad thing. I want my job to be easier.

I used to program black on white, then I was converted after jetbrains came
out with an excellent dark theme with huge color variants that make code pop
even better.

I'll never go back; I want my work and job easy, not made harder.

~~~
taneq
This was my thought - he's altered his style to be more readable without
syntax highlighting, which is all well and good for him, but doesn't
necessarily translate to it being more readable _with_ syntax highlighting,
and so is not necessarily a grand thing for his teammates who still use it.

------
eikenberry
I predict that in a few months the author will turn a toned down version of
syntax highlighting back on. All the advantages he stated were the result of
disrupting his previous practices. Doing that forces you to reconsider how you
do things and end up improving your skills. But they are learned lessons, not
some mysterious side affect of less color.

~~~
geocar
That's what robertmeta did[1], but when I turned off syntax highlighting I
left it off.

[1]: [https://www.robertmelton.com/2016/04/10/syntax-
highlighting-...](https://www.robertmelton.com/2016/04/10/syntax-highlighting-
off/)

------
pjmlp
No thanks.

The last time I could bare not using syntax highlighting I was still on MS-
DOS.

Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on
my programming environment.

But I understand when we are talking about vim, people prefer an hardcore
experience.

~~~
geocar
I first learned C on VMS.

When I could use Turbo C on my own computer in the 1990s, syntax highlighting
just came along for the ride. I learned vi from Watcom. I used vim. I wrote in
perl, and PHP. I also learned Emacs. I wrote in Common Lisp. Syntax
highlighting just stayed on.

And then I saw someone do something I had never seen before, and I wasn't sure
how to do, and I noticed they weren't using syntax highlighting.

So I turned it off.

~~~
taneq
Did you have any thoughts of your own about the before/after experience? Or
did you simply imitate them on the basis of learning an unrelated trick?

~~~
geocar
Yes. Maybe. I don't think I was thinking about it that way. I think it was
more like "look at how readable this is[1]", and when I opened it on my own
computer all the bright colours were suddenly very distracting so I turned it
off.

I would sometimes use ed to make changes to programs since I can see what I
was working on before I needed to make a change, so I don't think it was doing
anything for me, but at the same time I don't think I ever thought about
syntax highlighting until I tried to work with dense code.

I do try consciously to improve myself, but nobody knows how they program and
how to get better. The only strategy that has worked reliably: If I see
someone do something I cannot do I try their methods until it makes sense in
my own mind.

I've tried to write about this previously[2], but most programmers are hostile
when seeing someone do something they can't do, rather than just trying it,
they make up all sorts of reasons why they don't need to --"it's
unreadable"[3] is extremely common, but questions abou[4] is a new one on me.

As it stands: I don't understand syntax highlighting. I'm pretty sure that
syntax highlighting doesn't do anything for me in the best case. Maybe. But is
it bad? Is turning it off necessary to being a better programmer? I got better
when I turned it off, but it really might be a coincidence. I don't know.

[1]: [http://kparc.com/b/a.c](http://kparc.com/b/a.c) but not exactly.

[2]:
[https://news.ycombinator.com/item?id=8476294](https://news.ycombinator.com/item?id=8476294)

[3]:
[https://news.ycombinator.com/item?id=8477064](https://news.ycombinator.com/item?id=8477064)

[4]:
[https://news.ycombinator.com/item?id=12887021](https://news.ycombinator.com/item?id=12887021)

~~~
taneq
That seems pretty reasonable - if you can see that someone else can do
something you can't, and you don't know how, then there's no harm seeing what
they do differently to you and trying that just in case. Correlation doesn't
imply causation but it does suggest the possibility.

I know I prefer a much more muted colour scheme now than I used to. I still
like my syntax highlighting but it's more hinting than glaring RGB confetti.

------
gnuvince
This seems to be an over-reaction to overly highlighted code. I work with
Erlang in Emacs, and at first I couldn't believe how much of a Christmas tree
my code looked like: every token had its own color, and it was really hard to
read. Fortunately, erlang-mode has a setting to reduce the amount of
highlighting. I don't think the proper reaction to a code base that has too
many colors is to have none at all: trop c'est comme pas assez. I think many
would be happy with some limited highlighting, for example comments, strings,
and other constructions that can span multiple lines, incorrect escape codes,
possibly-misspelled identifiers, etc. I don't really need or care that
keywords and integer literals are colored differently.

------
fatbird
I have 2.5 major distinctions made in my syntax highlighting, and it's common
to almost all languages for me:

Comments are a shade that's near the background: I can read them if I focus on
them, but otherwise they're not present when I'm reading code

Strings are a colourful colour, because the next visual distinction I want is
between what's an operation or name, and what's data or literal. Numbers don't
get this treatment because they're sufficiently obvious on their own.

The base text colour has a small distinction between keywords (darker) and
everything else (lighter).

Sometimes I'll pull in another colour if I'm in something like Python for
things like decorators, to create a distinction between code and meta-code.

This takes care of 95% of the visual distinguishing that's useful, and the
rest is noise that adds cognitive load to track. As a bonus, because it's
common to all languages in which I work, switching is easy because almost
every language breaks down nicely between these categories.

~~~
chrismorgan
If making comments invisible is at all helpful, they’re being seriously
misused. Comments are supposed to explain what’s going on, and thus make
things _easier_. Hiding them _should_ be very counter-productive.

~~~
fatbird
As pYQAJ6Zm says: they're not invisible, but when I'm looking at code, they're
easily ignored, and when I'm looking at comments, they're easily located.
Using solarized dark, the background is Base 03 'bright black' (#002833) and
the comments are Base02 'black' made a bit lighter (#004f62).

Comments are for holding details: I shouldn't need them to understand code, at
least superficially/structurally. But they should be there if I need to drill
down on something a bit, and making it so that focusing on that extra detail
is easily skipped or applied makes the overall code reading much more fluid.

------
stevebmark
Not this again

"We should remove all color from traffic lights and make people remember which
position is what"

~~~
michaelmrose
Surely this would make people slow down and pay attention or you know just
crash more.

~~~
s_kilk
Right, but realistically they'd just crash more and then what's been achieved?
Some of us get to feel smug about how the daft plebs aren't hard-core enough
to navigate without colored traffic lights?

~~~
asp_hornet
not OP but I believe that was the point he was making

------
Animats
Syntax highlighting only helps with the easy stuff. It doesn't do anything for

    
    
        std::array<std::shared_ptr<Window>, max_window_count>{};
    

or

    
    
        s.lines()
            .map(|bline| UnicodeSegmentation::graphemes(bline, true)    
                .collect::<Vec<&str>>())
            .map(|line| wordwrapline(&line, maxline, maxword))
            .collect::<Vec<String>>()        
            .join("\n")
    

because nothing there is a language keyword.

~~~
jobigoud
> because nothing there is a language keyword

What editor are you using where the highlighter doesn't identify user-defined
types, member functions, namespaces, local variables? Maybe you don't realize
it has these capabilities because it's configured to highlight them with the
default?

------
the_mitsuhiko
I tried this multiple times over the last few years and it always didn't
matter. It's not making a measurable difference but it looks less pleasant and
I rather look at pretty things.

~~~
foobarian
I also don't find the syntax coloring to make a big difference for me. What
does though is the semantic feedback/navigation in the IDE.

When I joined a Java shop for the first time I was all gung-ho about sticking
to my 80x24 terminal and emacs and to heck with the point-and-click crowd who
couldn't do their work without a graphical UI. Then my new manager got me to
try Eclipse for a week. I humored him and discovered that I was an order of
magnitude more productive with Eclipse's semantic features like on-the-fly
compile error underlining, code autocomplete, and navigation. It really was a
humbling experience.

------
Philipp__
I found most of syntax highlighting easy distracting. But I couldn't turn it
off completely as it felt _weird_. What I did is I modified theme who's colors
I loved the most, so that it highlights less things, so that only some
keywords would be highlighted like (break, return, for, if, etc). That way it
helped me as screen didn't look to colorful, distracting and it didn't strain
my eyes as before, but still providing some necessary information that pops
out, to help me see the structure of my code better. But that is just me. I
think I am not yet ready to give up syntax highlighting completely, but who
knows, maybe one day. I am surely making progress towards that.

------
BaNzounet
Author should provide some before/after code to show how it affected his
coding style.

------
jstimpfle
> Conditional syntax highlighting

I think that's the right approach. Different situations afford different
tools. In normal usage, reading only in a single color is a real relief to me;
but of course it's typically easier to find missing delimiters and such with
syntax highlighting.

I've had this shortcut in my vim configuration for a very long time and I use
it frequently:

    
    
        nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><C-g>
    

Similarly, there should be actual different flavours of highlighting for
different tasks. I have configured a very light highlighting which highlights
mostly control flow words (if, while, for, return etc) and maybe strings. It's
much better than the colorful default or syntax off for many situations. On
other occasions it might be useful to highlight all variable declarations,
etc.

I have come to think that it's the same with programming languages: Different
languages require you to type different things explicitly. Sometimes that's
beneficial but often it hurts. For example, typing a function signature is
much more convenient in python (just variable names), but when debugging the
explicitness of a more rigid type system often helps finding bugs. Similarly
typing "const" or the precise type of integer is really annoying in many
situations. It's visually distracting and shifts the focus on alignment or
ordering of statements, instead of the problem to be solved. On the other
hand, sometimes these things are just important. It would be very nice to have
a programming environment where these details can be hidden most of the time
and only turned on when really needed.

------
drothlis
I like to highlight just the places where you are defining new
variables/functions/types so that the definition is easy to spot. What is the
point of highlighting keywords? I suspect that highlighting engines do it
simply because it's easy to do, not because it's useful.

It looks like this:
[http://david.rothlis.net/code_presentation/distracting_synta...](http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/)

~~~
Adverblessly
To me, all three look bad.

Eclipse - no colors for different things, hard to find what I'm looking for
(if I compare to the Emacs example, if I was looking at this code trying to
figure out what members this class has I'd be looking for brown and finding it
much more quickly)

Emacs - terrible color scheme, both the brown and the green are too bright,
not enough contrast to read.

Proposed - all the bold text hurts my eyes and distracts me from everything
else.

In my crazy theme almost every "thing" has its own color, and it is very easy
to find what I want by looking for the right "thing" or combination of things.
As an example for where highlighting keywords would help (which is what you
mentioned in your post), if I'm looking for "that for loop that does the main
logic" I'd look for the place with the small blue blob on the left and a long
bright blob to the right (if it was an "if" likely both blobs would be smaller
;)).

------
bbarn
On an average day, I use visual studio for 4 languages. There's C#, HTML, JS,
and some old VB.net depending on how old the code I'm working with is. Many
times the same fix/feature will touch all of them. That's just on the .net
stuff. Having the same general colorization scheme in place is probably all
that makes skimming through code possible for me.

I remember feeling like the game changed when I went from grey and yellow on
black to grey and holy crap other colors for other things on blue from turbo
pascal 3 to 7. You can't take it back from me now. I've had my syntax
highlighted for 2/3's of my life now, I'm not giving it back.

------
zvrba
Yes, let's use roman numerals too lest we calculate too efficiently and be
able to express more complex calculations more easily.

~~~
Mr_T_
You mixed it up.

Syntax highlighting is like doing arithmetic using colored rods:
[https://groups.google.com/forum/#!msg/golang-
nuts/hJHCAaiL0s...](https://groups.google.com/forum/#!msg/golang-
nuts/hJHCAaiL0so/kG3BHV6QFfIJ)

Roman numerals is object-oriented design:
[https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff...](https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff_uWhnsbwAJ)

------
jack9
This seems like old-is-new waxing, reaching for some reason the old way is
better.

> Initially, turning off syntax highlighting felt weird. I couldn’t skip
> through the source that fast anymore and it became harder to read.

It does, that's the point of syntax highlighting. This isn't a good thing(tm).

> Even though this appeared to be an impairment I found it to be the strongest
> argument for making the switch. By forcing me to read the code more
> carefully, it made me understand it better

I tried not highlighting a bunch of times, it's called switching from my IDE
to vi for whatever reason. It's not better for me.

~~~
jablan
You know that vim can syntax-highlight too, right?

------
codepunker
Let's not use headlights anymore too... This will force the us to drive more
carefully and reduce speed to avoid a potential disaster.

~~~
dudzik
"The removal of road markings is to be celebrated. We are safer without them"
\-
[https://www.theguardian.com/commentisfree/2016/feb/04/remova...](https://www.theguardian.com/commentisfree/2016/feb/04/removal-
road-markings-safer-fewer-accidents-drivers)

------
twblalock
I think syntax highlighting probably evolved before editors and IDEs could
flag coding mistakes. A lot of the rationale for it no longer applies, e.g.
coloring strings a certain way so if you forgot the terminating quotation
mark, the rest of the file would change to that color and you'd know you
screwed up.

I haven't used syntax highlighting for years. My IDE highlights mistakes and
compiler errors, and everything else is black. It's actually a lot easier on
my eyes, and the errors stand out a lot more because they are the only colored
parts of the text. I only use highlighting these days to separate tags from
content in markup languages like XML and HTML, where I still find it helpful.

This is all personal preference anyway, and it doesn't matter very much. But I
do encourage people to try going without syntax highlighting for a few days.
You may find that you didn't really need it, or that it was compensating for
sloppy coding, and you may not want to switch it back on at the end of the
experiment.

------
apetrovic
Even better - we should ditch color monitors altogether. You know, to be edgy
and different.

~~~
rsl7
Sure, also let's chuck scrollback in our terminals. What's done is in the
past, people.

~~~
vacri
A shiver actually ran up my spine...

------
mseepgood
Turning syntax coloring off was the best decision in my career. I have never
looked back.

~~~
dimman
I wouldn't go as far as to say it was my best decision in my career, however
it was an important one. I've noticed how I've gone from "click-friendly"
GUI's and window managers like Gnome/KDE to Fluxbox, turned syntax
highlighting off and at the same time increased my productivity/effectiveness.
At first I missed the "fanciness", the new felt boring and pale, however as
time passed it made me realize that I'm now focusing on the important things
and I'm in control. So yes okay, it's one of my best decisions.

------
tambourine_man
I worked for years with SimpleText/TextEdit on the Mac (Classic/OS X) and Pico
on the server.

I felt syntax highlighting was a gimmick that distracted me from my Monaco 10
with no anti-alias perfection. If I needed to do some repetitive editing
beyond a simple find/replace, I'd write a small shell script. I was kind of
proud of my minimalism. You can do a lot with native Carbon/Cocoa key bindings
alone. Life was good.

Then someday I saw a video of someone doing crazy work in Vim. Flying. I _had_
to learn that. I forced my self to use Vim exclusively for one job, from
beginning to end. I kept watching similar videos to get over the nightmarish
frustration that is anyone's first week or so in Vim. But after that, I was
completly hooked.

However, I still have warm feelings when I open some code in TextEdit. Black,
10px Monaco text over a 90 by 30 white background. Ah.

------
CalChris
This experiment applies to textbooks as well.

I looked over an old edition of Halliday+Resnick once, a well thought of lower
division physics book. The text was substantially the same but it was black
and white. This meant no _syntax highlighting_ and also no glossy paper. The
result was a LOT easier to read.

Glossy paper is a designery thing to do for deeper blacks but it's less
readable. Indeed that's why actual designers like matte finish MBPs, because
you don't want to read with a 20% opacity of yourself staring at you.

------
kpil
Ok, this thing with young developers going into grandfather-mode is starting
to get old.

Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and
carry on with your life.

------
yitchelle
Coming from an age before syntax highlighting was a thing, I would hate for us
to go back to it. I first saw it in Turbo C and it was amazing. This is
another tool that we can use to give us better code quality.

However, some folks is pushing the syntax highlighting into realms of an art
piece. I had a coworker that would using bold, italics, different font sizes,
as well as colours.

------
aratno
I totally agree with this, and use `:syntax off`, but comments really mess
with visual clarity. For dimmed comments, I sometimes switch to nofrils.

[https://www.robertmelton.com/2016/04/10/syntax-
highlighting-...](https://www.robertmelton.com/2016/04/10/syntax-highlighting-
off/)

~~~
mseepgood
Comments are the most important part of code. They should not be dimmed. If
anything, they should be the only thing that is highlighted.

~~~
aratno
I'm arguing that dimming them makes them easier to see. Code and comments are
interspersed, and are each harder to see when they're the same color.

~~~
majewsky
I use a slightly more intense background color on comments to make them stand
out while still being readable enough.

------
vbezhenar
I don't turn syntax off, but I hate rainbow in my IDE. I usually use bold for
keywords, different colors for comments and string literals, underscore for
class members (for Java). Basically that's all. I don't need any other
highlighting, it's just a noise for me which makes it harder to read the code.

~~~
qznc
What I don't understand is that people want to highlight _keywords_. Bold is a
very strong highlight compared to coloring it. However, keywords (if, while,
return) can probably be guessed from the indentation alone. There is little
need to guide my focus to them even more.

~~~
protomikron
Interesting, for me it is the other way around. I use syntax highlighting (but
mostly go with Vim's shipped defaults) and like the keyword highlighting the
most.

E.g. looking at Python code, it highlights 'def', 'if', 'else', 'elif', 'for',
'while', etc. in orange, function identifiers in cyanish and literals
(integer, float, strings) redish (on terminal with blackish background).

If I look at code, it helps me to find the beginning of a function and the
parts where logic branches (conditions, loops, etc.) start. Some time ago I
wrote code without highlighting and although it is obviously possible I found
it harder (i.e. it took me more time) to navigate for my eyes. Maybe just
using bold or italic would be enough, though.

However thinking about it, it might be a nice experiment to highlight
identifiers with a unique color (or at least highlight all occurrences of an
identifier below the cursor - I think Eclipse does something like that).

------
jablan
It probably goes well with typing on one of these horrible new Macbook
keyboards - it makes you think twice before pressing each key, thus making
your code even more thought-out and succinct.

As one of those programmers who were long ago forced to use no syntax
highlighting (because monitors were monochrome), I say no thanks.

------
jug
I think he may have a point, but I think there's a minimal highlighting
configuration that is helpful, yet not obnoxious: one where comments and
constants are highlighted in their colors.

Comments are pretty much universally "skimmable" if what you want to get at is
the code, and also completely unrelated to actual code (other than describing
it), so I think they deserve their own color and that it is helpful. Also,
conversely comments in their own color stand out from the code so that if
you're looking for descriptions, they are easier to find.

Colors also being useful for constant values (strings and numeric ones alike)
because at least I really want something hard coded to stand out. Sometimes it
should be hard coded, sometimes it shouldn't, but pretty much always, what the
hard coded content _is_, is of interest.

------
djhworld
I don't agree with the idea whatsoever, but I really like the minimalist
design of the authors website.

------
Yaggo
I do use syntax highlighting, but only with two additional subtle colors (one
for literals, another for language keywords). Many editors come with themes
resembling a decorated Christmas tree.

------
Rudism
I'd argue that you could learn to read code carefully, understand what it's
doing, and write good code without losing the convenience of syntax
highlighting.

Unless the color scheme you were using really was so garish that it hindered
your ability to improve your skills as a software engineer, in which case you
could probably find a more subtle color scheme that would give you the same
benefits as turning it off did. I've heard great things about the solarized
color schemes. I use wombat myself.

------
Kareeeeem
Not sure about all the benefits and whatnot but I've learned to like 'syntax
almost off' better. I do want to differentiate between comments though. And
vim adds some of it's own colors to stuff like the linenumbers that I dislike.

So I use this. [https://github.com/Kareeeeem/vim-
walou](https://github.com/Kareeeeem/vim-walou)

There's more stuff like it but I wanted to pick my own gray values and dislike
pure white on pure black.

------
rcarmo
The Acme/Plan9 folk were bullish on coding without syntax highlighting (and
with proportional fonts). I spent a while trying to use Acme a couple of years
back and agree that it's not essential, but I switch programming languages so
often these days (Python/Go/Clojure plus the occasional Java/C#) that I need
it to remind myself of what goes where in each language.

But I can see the benefit of forcing you to make your code more readable in
general.

------
z3t4
I only color comments and strings.

~~~
satysin
Same. Works well for me e.g.
[http://i.imgur.com/RMrslmu.png](http://i.imgur.com/RMrslmu.png)

~~~
qznc
Comments and literals (numbers, strings, NULL, etc) here.
[http://imgur.com/a/kRbhG](http://imgur.com/a/kRbhG)

I tried no-syntax-highlighting for a while, but found that a little bit is
nice.

------
iKlsR
My solution for half a year now, after years of a bajillion themes, it's hard
to go back, using a light theme with dark text works to an extent but I code
mostly at night so I need a dark theme in general. Just use about 2 shades of
grey and one other soft color.
[https://i.imgur.com/FHALH2G.png](https://i.imgur.com/FHALH2G.png) \-- or
search for Phoenix theme

------
dinhnv
In my team, an old geek man also have told me about `syntax off`. I also have
tried a couple of times. But it makes my eyes hurt cause of looking carefully
at every word, tokens. Another thing I consider to build my workspace is
'attractive'. Code with proper color highlight make it sexy to work with.

------
z0r
syntax off, proportional width,
([https://twitter.com/rob_pike/status/567476552187641856](https://twitter.com/rob_pike/status/567476552187641856)),
all code right aligned, ZWS for tabs

~~~
TurboHaskal
\- Hey guys we wrote gofmt so all code looks the same.

\- Great! Now we can finally get things done and stop bikeshedding!

\- Now about that syntax highlighting of yours...

------
k__
I have the feeling most of this isn't a direct problem of syntax highlighting.

Most people simply highlight dumb stuff in their code.

For example, comments often have a bad contrast and stuff like brackets, curly
braces or parathesis have high contrast.

------
barat
Is there any example for this so-called conditional highlighting that we could
take a look at ?

------
return0
I thought broscience was supposed to stay in the gyms.

------
jowiar
I think a large part of the issue with syntax highlighting is that our
"standard" for syntax highlighting is rather dumb. A few thoughts:

\- Who the hell would write prose by making all the verbs blue, the nouns red,
and the adverbs green (or something to that effect). That's what we do for
code. Something togglable a-la iA Writer might make sense, though. At the same
time, I can sort of understand, though, because we're almost always in "edit"
mode for code, very rarely in pure "write".

\- I find having lint-errors highlighted provides a similar nudge to the
"squiggly-red underline spellcheck".

\- Our editors aren't configurable enough with regards to typography. I like
to use subtle weight changes, highlighting "headings" and whatnot, and very
few tools seem to make that change available.

\- Semantic highlighting seems super interesting, but I haven't found a tool
that I like yet.

One project I'd love to see is to get a bunch of folks together to do some
proper layout-by-hand on code -- Given 100% control over typography, how would
you format it to maximize readability, minimize distraction, highlight
relevant contextual knowledge, etc? And then work to push tools in a direction
that they support configuration to allow for said tasks.

~~~
qznc
Yes, nice idea. For example, it might be helpful to have different colors for
local variables, global variables and fields. If you accidentally shadow a
variable, you might notice this way.

Likewise, highlight macros in C and make them different to
variables/functions.

~~~
cygned
Something like this?

[https://github.com/jaxbot/semantic-
highlight.vim](https://github.com/jaxbot/semantic-highlight.vim)

~~~
qznc
From reading the README, it just cycles through colors. The colors are random,
not semantic, so the name seems to be misleading?

~~~
cygned
Haven't tried it yet, just bookmarked it. So I can't review it.

------
ncauneia
Is disabling syntax highlighting the new standing desk?

------
douche
I like to take advantage of my tooling to make my life easier. Writing good
code is difficult enough without imposing additional constraints upon yourself
to make it more challenging.

------
draw_down
No, no, no.

