<p>I am curious why official web-site is not using syntax highlighing on code examples? What is the philosophy under this? </p>
<p>I find it very unfriendly for learner.</p>
<p>My short research did not give any answer to this.</p>
<hr/>**评论：**<br/><br/>kevinherron: <pre><p>Because Rob Pike wants you to take your juvenile syntax highlighting and get off his lawn.</p>
<p>/sarcasm, <a href="https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0so/kG3BHV6QFfIJ">kinda</a></p></pre>vyasgiridhar: <pre><p>How did you find that out?</p></pre>mcouturier: <pre><p>Wondering if the go code of conduct was in effect back then...</p></pre>dgryski: <pre><p>It was not. Previous threads have pointed out that if it was, Rob probably wouldn't have said that or would have been called out on it.</p></pre>FUZxxl: <pre><p>The authors aren't very fond of partylight mode.</p></pre>goomba_gibbon: <pre><p>I personally find syntax highlighting useful. I can't really think of a reason not to have it.</p>
<p>I'll admit some colour palettes can be harder to read but that's quite easy to avoid.</p></pre>enneff: <pre><blockquote>
<p>I can't really think of a reason not to have it.</p>
</blockquote>
<p>I personally find it distracting.</p></pre>Pulse207: <pre><p>Same. I like two shades of gray and pink strings. Anything more is grating after a while.</p></pre>nicolas42: <pre><p>It distinguishes between comments and code </p></pre>charliegriefer: <pre><p>I understand that this is a divisive issue. I'm surprised, but I understand it.</p>
<p>Shouldn't be too hard to give the user the ability to toggle syntax highlighting on/off, no?</p>
<p>Then, everybody's happy. Or, at least, we find something new to bitch about :D </p></pre>outroot: <pre><p>You can use a user script to highlight it. You can use mine, make your own, or modify it to your liking.</p>
<p><a href="https://github.com/kdar/go-highlight-userscript" rel="nofollow">https://github.com/kdar/go-highlight-userscript</a></p></pre>andradei: <pre><p>I used to ask that myself all the time. But reading this thread I can't help but to want to try programming in Go with syntax highlighting turned off now, just to see how it goes.</p>
<p>I realize now that I've trained myself to recognize colors rather than tokens and keywords... I need to correct that.</p></pre>dmikalova: <pre><p>Why? If it's a useful shortcut why waste the mental cycles?</p></pre>andradei: <pre><p>I'll try it out for a week and see for myself whether the cost pays any benefits.</p></pre>dericofilho: <pre><p>I came from a time where most computer displays were monochromatic - so no syntax highlighting. I used syntax highlight for a period of time. The truth is that my brain works best without highlight, not because they aren't useful - they are - but because you do not restrict the meaning of a symbol by the color. It is tricky to realize this. </p>
<p>Just to give a glimpse what I mean: in Go you may declare a variable to hold a function as a value. Of course the highlight will color it as the variable it is. It turns out that our notion of variable is dramatically different than of a function (after all variables don't run anything). </p>
<p>Without highlight, the meaning is the name. With highlight the meaning is a mix of name and color, which creates a small brain overload.</p>
<p>In a more intuitive approach, think of that case in which people are asked to tell the color of a word that does not match the printed color (a word "red" printed in blue for instance) - similar phenomenon happens when you use highlight when coding. </p>
<p>Beautiful. Feels good. But it backfires in subtle ways. </p>
<p>YMMV, but the number of bugs in my code dropped immediately after I stopped using highlight. I do not think it is a coincidence. </p></pre>kisielk: <pre><p>I agree with the decision not to use syntax highlighting, particularly in documentation.</p>
<p>If a code example isn't understandable without syntax highlighting, it's probably not a well-constructed example.</p></pre>cheesechoker: <pre><p>The point of syntax highlighting IMO is not to make code <em>understandable</em>, but to make it faster and easier to understand.</p>
<p>It's a visual aid to comprehension, like quotation marks in a novel. Given that humans have remarkably advanced facilities to recognize visual cues, it's a shame to force people to read and process token-by-token, and build up a mental structure when the computer could instead trick your brain into doing part of that work.</p>
<p>For newbies, good highlighting also gives valuable clues about the syntactic structure of the language: which of these things I'm looking at are keywords, and which are arbitrarily chosen by the sample code? You can get a fair idea at a glance.</p>
<p>Again, careful construction of sample code and careful reading could probably accomplish the same thing, but why not use shortcuts when you have them and they cost very little to employ?</p></pre>NeverUse-YouPromised: <pre><p>(<strong>Note:</strong> not <strong>sarcasm</strong>) I <em>wish</em> ordinary <strong>communication</strong> <em>had</em> SYNTAX <strong>highlighting</strong>, for <strong>example</strong>, all <strong>nouns</strong> BOLDED, all <strong>verbs</strong> ITALICIZED, and all <strong>adjectives</strong> CAPITALIZED.</p></pre>small-wolf: <pre><p>"Syntax" is not an adjective in that sentence. It should be bolded, unless the rule is only heads of NPs get bolded.</p></pre>NeverUse-YouPromised: <pre><p>The <strong>rule</strong> <em>is</em> only <strong>heads</strong> of NOUN <strong>phrases</strong> <em>get</em> BOLDED.</p></pre>idevxy: <pre><p>German kind of does this. Nouns are always capitalized, whether they are at the Beginning of a Sentence, in the Middle, or at the End. It's actually pretty helpful for learning the Language in my Opinion.</p></pre>kisielk: <pre><p>One issue I have with syntax highlighting is that it indiscriminately highlights things based on the language syntax. That's fine when you're editing code and need some visual indicator of the structure to be able to navigate quickly without actually reading it, but I don't think it's that suitable for documentation. </p>
<p>In a documentation example it may put more emphasis on elements that aren't as important to what the example is illustrating.</p>
<p>If a lack of syntax highlighting in documentation makes your reading slower I would argue that's a good thing. Slowing down and spending more time reading is helpful in actually trying to understand what you are looking at. </p>
<p>Besides, the Go documentation <em>does</em> have highlighting to a degree. Comments are in green to de-emphasize them. Identifiers from other packages a highlighted in blue and serve as a cross link to the other package's documentation. That's plenty.</p>
<p>Go only has 25 keywords, it shouldn't take long to get familiar with them, so I don't really think there's much point in highlighting them.</p></pre>andradei: <pre><p>Very interesting. I think I am dependent on syntax highlighting as of right now, to the point I can't easily understand a piece of code that doesn't use it.</p>
<p>I wonder if I'll be able to understand code better if I'm forced to parse the keywords and tokens by what they are rather than by what color they have.</p>
<p>I'm going to try it right away, for a couple of weeks, and see where it goes...</p></pre>drvd: <pre><p>Go's syntax is simple, Go has not many keywords so syntax highlighting is not that useful except colouring comments and strings.</p>
<p>The main problem is one of taste: There is no "syntax highlighting" there is just "syntax highlighting by a particular colour scheme". Now we all know that only gruber-darker is a suitable colour scheme but most people have different (read "bad") taste and prefer a different scheme. What looks like a string too you might be a comment to me (because of your bad taste and wrong choice of colour scheme ;-). Better to stay far of this battlefield of style for official documentation.</p>
<p>There is one thing <em>not</em> taste related in color scheme selection: dark vs light schemes. Dark is considered more comfortable for long work but unreadable under some conditions (shiny display, direct sunshine). So a binary light scheme as used seems a good compromise: Readable under all conditions and taste/preference-neutral.</p></pre>Orange_Tux: <pre><p>Maybe because the examples are often quite small and adding syntax highlighting would not add much value to readability and/or understandability.</p></pre>vimaana: <pre><p>Clearly because the <strong>authors</strong> do not <strong>value it</strong>. Perhaps because <strong>syntax highlighting</strong> has the effect of leading one to conclusions about what <strong>is important</strong> in the reading. While I have learned to use this as a crutch in someways and rely upon it syntax <strong>highlighting</strong> can be an impediment to not only the <strong>comprehension of</strong> the code but also an interruption in composition of <strong>the code</strong>.</p></pre>binaryblade: <pre><p>there is a difference between emphasis and colouring</p></pre>Manbeardo: <pre><p>Color and line weight are different, but they are also both scalars that your visual cortex shortcuts and processes before you reason about them.</p></pre>idevxy: <pre><p>Personally, I find syntax highlighting <strong>rather useful, ** especially for cases where I accidentally forget a closing quote or similar.</strong></p>
<p>For example, view the source of this comment and you will see how much harder it is to tell that the markdown was done incorrectly.</p></pre>YEPHENAS: <pre><p>A case against syntax highlighting: <a href="http://www.linusakesson.net/programming/syntaxhighlighting/" rel="nofollow">http://www.linusakesson.net/programming/syntaxhighlighting/</a></p></pre>m3wm3wm3wm: <pre><p>Because, Go.</p></pre>GoTheFuckToBed: <pre><p>Lets vote on it</p></pre>coredump777: <pre><p>Maybe because deciding what color scheme to use would cause a civil war.</p></pre>thepciet: <pre><p>You can't encode syntax highlighting in UTF-8, haha oops.</p></pre>
