Syntax highlighting

[jack]

How much syntax highlighting do you generally get when you edit code? Any?

Does it call out different variable types?

Can you easily configure it dynamically to eg. highlight different ifdef branches or variables with certain prefixes?

Should it be able to?

Comments

[ptc24.livejournal.com]

Living as I do in the JavaVerse, a fancy IDE is essential for not dying of verbosity. Eclipse is my default, I don't know how configurable it is. Variable names are highlighted as being static, non-static or local to a method, but there's no type highlighting beyond that.

When I did lots of python work, well, it's dynamically typed, so no type highlighting there.

I'm not convinced that type highlighting is universally useful, given dynamic typing, type heirarchies etc.

[ewx.livejournal.com]

I'm not sure highlighting the types of variables is likely to be that helpful; what you need to know about a variable (or any expression) is what it means not merely what type it is. Still, I'd be willing to try it, though I think it'd be rather a lot of work to add the feature to Emacs (my answer to your first question being pretty much the font-lock-mode defaults).

[hoiho.livejournal.com]

Given that emacs font-lock works on regexps, I'd say that it'd be tantamount to impossible to add it (you'd have to dynamicaly update the regpexs with the names/type/style tuples...). Even etags (which has a more or less complete C parser) has trouble with this sort of thing - hence the flags for typedefs.

[ewx.livejournal.com]

Indeed - by 'rather a lot of work' I imagine a fresh start.

[hairyears.livejournal.com]

Blue for reserved words, green for comments, red for anything the compiler thinks is a syntax error.

If you want visual cues for anything else, you have to rely on careful indentation and layout. Which, of course, I do...

Which leads to a related question: how do you lay out SQL (and maybe other code, although most languages have conventions) so that you can get immediate visual-cortex input into your first read-through of the code, rather than mumbling through the text and waiting for the words to come together and give you an overview of the logic structures?

[simont]

My syntax highlighting is done by Jed. It's purely lexical: it distinguishes between keywords, identifiers, numeric literals, string literals, operators, delimiters, comments and preprocessor directives, but nothing cleverer than that. It doesn't do anything at even the syntactic level, let alone semantic; so it can't even tell the difference between a typedef name, a structure tag, a variable, a structure member and a macro, and it certainly wouldn't be able to tell the type or scope or constness of a variable. And it doesn't speak preprocessor, so it won't highlight ifdef branches either.

I could, I suppose, configure it to highlight variables with a particular prefix, since that can be done at the purely lexical level. However, you specified "easily", and it certainly wouldn't qualify as that: I'd have to reimplement chunks of the standard C mode in my .jedrc and have them override the normal version. Also, I'd run out of colours.

As for "should" ... I'm not sure. It's possible that I might find uses for such functionality if it could be easily done; but I've never felt its lack. More generally, one might present various arguments against making syntax highlighting too complicated:

• it would slow the editor down
• it would encourage people spending more time configuring their highlighting scheme and less time coding
• the closer the editor comes to fully understanding the source language, the more people will tend to work on the assumption that it will always agree with the compiler, leading to significantly greater inconvenience on the few occasions when it doesn't
• writing editor modes for new languages becomes a lot more effort.

On the whole I think I'm happy with the level of highlighting I have now: simple to implement for a new language, quick to perform during editing, and relatively robust in the face of things the editor doesn't understand.

[angoel.livejournal.com]

Pretty much none, because to have syntax highlighting you need an editor which is capable of doing it, and those are invariably stuffed with 'features' which make my skin crawl.

Plus, I tend to find that highlighting draws my attention sufficiently that I can't read the non-highlighted stuff without disproportionate effort, so it tends not to actually be all that helpful.

This may change if I had to create larger projects.

[yrieithydd.livejournal.com]

In my limited experience, (which is basically TeX related)* the most useful thing is something which keeps track of brackets! When I started hacking .bst files I was only using notepad which led to me on occasion sitting in the library going through a definition counting brackets on my fingers muttering `open bracket, open bracket, close bracket, open bracket etc) to work out where I'd missed one. Using WinEdt made life easier as it tells you which bracket it things each one is closing. Though it does get a bit tangled up with different bracket types at times.

*Apart from some Basic as a small child (well under 12 anyway when we moved onto an A3000 from the electron).

[chess]

I have full-on Visual Studio + Resharper code highlighting.

I have it set to distinguish built-in types from types defined somewhere in my solution, but no more distinction between variable types than that, and no highlighting on the actual identifiers.

There's a system for highlighting variables with certain prefixes but I tried prefixing my variables once and didn't like it much, and with comprehensive Intellisense / go-to-definition there isn't much point (the information is sufficiently close-to-hand that prefixes are just clutter).

The code highlighting plays well with the very limited C# preprocessor and would probably handle C preprocessor if I put it in C++ mode.

There are about a million different extra highlighting options that I have turned off because I ran out of non-distracting, easy-to-read, easily-distinguished, pleasant colours. But it's nice to know they're there - if I had a different code-base I'd probably use different features.