Syntax Highlighting / Code Colouring

(shameless abuse of current reddit karma - if you are in London and interested in Perl you might like to check out this years London Perl Workshop, it's free and it should be a pretty good day - although i'm biased as i'm the organiser - Greg)

I normally don't like syntax highlighting, I find it more irritating than I find it useful - probably because I don't need a crutch to understand the syntax as well as a computer can interpret it.

But I've just been reading an old email by Schwern that talked about traffic lights (a subject dear to my heart) and Perl 6 - and while he was intending to discuss the non-colour aspects of traffic lights it sparked a thought in my head about Perl 6 and colouring.

And I realised I had at last a use for code colouring, in fact I had lots of uses.

• When Perl 6 arrives I'd like a two colour system that indicates whats a new Perl 6 feature and whats an old Perl 5 feature. (this was the one that sparked the train of thought)

• When I'm being a maintenance programmer I'd like a colour system that indicates the age of the code sections when I'm tracking down a newly found bug.

• When I'm being a code reviewer I'd like to be able to tell what is covered by unit tests and what is not.

• When I'm optomising code I'd like frequence of execution mapped to the colour so I can see the hot spots in a nice hot red.

The question is now, how much can I be bothered to hack around with elisp to get any of the above working.

Comments

[Greg Mccarroll]

* Colouring based on the reputation I perceive of my fellow programmers working on the code base.

[Josef Assad]

Coloring to suggest style. Some of this might be real easy, like highlighting code at fourth level of indentation or higher, etc.

[Georgi Dimitrov]

More on code highlighting - http://mindprod.com/project/scid.html

[blah]

When I'm being a code reviewer I'd like to be able to tell what is covered by unit tests and what is not.
>>> It's called code coverage:), there are many tools that show a diff-like view of code coverage.

[ahnaqsh]

Great Ideas! Thanks. :)

[dgurba]

For highlighting coverage, an example application:
http://eigenclass.org/hiki.rb?rcov

example output of areas which are covered more than others (note no syntax highlightling, just frequency of coverage):
http://eigenclass.org/hiki.rb?rcov#l8

cheers

[Jonathan Tang]

Functional Developer, now part of the OpenDylan project, had syntax highlighting based on profiler results. I found it a little distracting, since I was still in the "writing code" mode and hadn't yet gotten to the "performance tuning code", but folks who *had* optimized large Dylan programs found it very helpful.

http://www.opendylan.org/~housel/fundev-snapshot.html

[Reinier Zwitserloot]

You can also use colouring and/or style to convey known information that is not obvious from the particular snippet you are staring at. One example 'in the wild' is eclipse's default choice of italicizing any static members - something that isn't obvious unless you are in the habit of writing source files less than a screen long.

The practical amount of such information available to the editor is limited by how much the project you're working in relies on Dynamic Meta Programming, though.

[Johan L]

I have actually been thinking for a while about doing exactly those things in PerlySense + Emacs (no short-term plans though, but the ideas are there).

I'm imagining a left hand column with color coding or some kind of icons for these things, so it's always there, but in an unobtrusive way so it's not in your face. More subliminal than anything else.

Another thing I've been thinking about is to do copy-paste / duplication analysis on a source tree and indicate that in the source as well. Then hit a key to show all other places where this piece of code seems to be present.

BTW, just the other day I read about the Augment Ruby tool which seems to be about the same kind of thing.

http://augment.rubyforge.org/

[Cameron Desautels]

"colour system that indicates the age of the code sections"

Emacs does precisely this with the VC-ANNOTATE command. e.g.

http://www.ganaware.jp/archives/images/svn_annotate.html

[Michael Feathers]

I made a similar plea a while back: http://beautifulcode.oreillynet.com/2007/10/skinny_languages_and_fat_tools.php

[Chris]

"I don't need a crutch to understand the syntax."

Neither do I, and neither do most people (in my experience) that use syntax highlighting. It's convenient for a ton of reasons, none of which have to do with understanding syntax.

[soft_guy]

"When I'm being a code reviewer I'd like to be able to tell what is covered by unit tests and what is not."

Use a coverage tool and run the unit tests.

"When I'm optomising code I'd like frequence of execution mapped to the colour so I can see the hot spots in a nice hot red."
Most optimizing tools do this already.

"When I'm being a maintenance programmer I'd like a colour system that indicates the age of the code sections when I'm tracking down a newly found bug."
That's a brilliant idea.

[john]

And I'd like a color to indicate whether I was on crack or coffee when I wrote each code section.

[Person You're Better Than]

I normally don't like syntax highlighting, I find it more irritating than I find it useful - probably because I don't need a crutch to understand the syntax as well as a computer can interpret it.

Well I'm glad to know that you are in every way my superior. Elitist arse.

[ethan]

i wish this blog used more highlighting. it's really hard to tell where one comment ends and another begins.

[anjan bacchu]

""When I'm being a maintenance programmer I'd like a colour system that indicates the age of the code sections when I'm tracking down a newly found bug."
That's a brilliant idea."

+1

I'm told that some SCMs have the capability of informing who wrote what line(s) of code. Using this kind of info, your IDE should be able to display the info above using colors and/or markers, etc.

BR,
~A

[Vic]

Highlighting is not about making syntax understandable. It's about helping to quickly identify simple errors. For example, people often miss obvious mistakes, like when 'the the' is twice in a sentence. If anything your ideas would add to the confusion of the programmer and while interesting I can't see much value in them.