\n<\/span>
\nThe following is a bit of source code as presented in BlueJ’s editor:
\n<\/span>
\n
![\"syntax](\"http:\/\/www.bluej.org\/mrt\/wp-content\/uploads\/2006\/07\/_Users_mik_Sites_iblog_B2002791029_C1916402003_E2024643120_Media_code-current.gif\")
<\/p>\nAs we can see, the syntax highlighter distinguished several classes of tokens:<\/p>\n
\u2022 javadoc comments<\/strong> \u2013 blue Reflection \u2013 what does syntax colouring do?<\/span> Lexical syntax colouring is based on information directly derived from a lexical analyser. The source character stream is divided into tokens, and those tokens are sorted into classes. Colour is then assigned to classes of tokens.<\/p>\n The problem with this is that some of the lexical token classes are of little value to make the source code more readable for a programmer.<\/p>\n Why, for example, is the word ‘int’ coloured red in the field declarations, but ‘String’ is not? Why does ‘abstract’ have another colour than ‘class’? Why is ‘public’ in the method header the same colour as ‘return’ in its body \u2013 are they somehow related? Why is ‘super’ different?<\/p>\n We should approach this question by asking ourselves what the purpose of syntax colouring is. Does the colouring above do this? Well, partly yes, partly no.<\/p>\n The one aspect where this succeeds in the above example is the distinct presentation of javadoc comments. This helps a lot separating the comment from the implementation, and also in separating methods from each other. But this is rather coincidental: it works, because a lexical token coincides with a logical structure.<\/p>\n The colouring of different keyword classes, for example, is not especially helpful.<\/p>\n What should syntax colouring do?<\/span> \u2022 separating interface from implementation Highlighting javadoc comments should be retained, since this is the one thing that is very helpful in the current scheme. In addition to this, we should:<\/p>\n \u2022 highlight the class header and the complete method signature<\/p>\n Finding the signature of a method is important; a programmer has to do this often. Field definitions are a separate logical entity that should be easily identifiable.<\/em><\/span><\/p>\n \u2022 distinguish between private and public fields<\/p>\n Private and public field serve different purposes and have important differences<\/em><\/span> \u2022 highlight control structures<\/p>\n The control structure highlighting should make it easy to recognise the parts<\/em><\/span> \u2022 separate methods, constructors, field definitions and inner classes<\/p>\n The most obvious structure of a class is the division into its members. This In addition to colouring these main structural aspects, there are two other things that might be helpful: I like the different colouring of strings, as they make some methods more readable, and it might be good to retain some colour for reserved words in method bodies to distinguish them from identifiers.<\/p>\n The next question then is: what should it look like?<\/p>\n The obvious mechanism that is usually employed is font colour. This will remain an important aspect.<\/p>\n Another possibility would be type face styles (bold, italics) or different faces. I have not used this for now. Styles, such as bold, are not supported well for all fonts on all systems, and I fear that we might be getting into technical problems more than it’s worth. So I leave this as an open question for now.<\/p>\n But another possible, underused technique, is background colouring, and other graphical annotation. To give you an idea what I mean, consider the following example.<\/p>\n Structural syntax colouring \u2013 an example<\/span> Method signatures are highlighted, and public and private field definitions are distinguished.<\/p>\n This is just a quick screenshot mock-up to demonstrate an example. The actual colour values are debatable, and can no doubt be improved. I also think that people can come up with other ways to highlight logical code structure. But you get the idea, I assume.<\/p>\n Let’s get rid of letting technical incidentals dictate the appearance, and make it useful for the reader! Syntax colouring \u2013 the annotation of source code with different colours for keywords and other syntactic tokens \u2013 has become standard in just about all development environments. Yet, it often does not make sense. I don’t mean to say that … Continue reading
\n<\/span>\u2022 other comments<\/strong> \u2013 although the colour is so similar to the javadoc comments that it is hard to distinguish
\n<\/span>\u2022 strings<\/strong> \u2013 green
\n<\/span>\u2022 keyword class 1<\/strong> (abstract, private, public, if, else, etc<\/em>.) \u2013 dark red
\n<\/span>\u2022 keyword class 2<\/strong> (class, int, and a few others) \u2013 bright red
\n<\/span>\u2022 keyword class 3<\/strong> (super, null, this, etc<\/em>.) \u2013 light blue<\/p>\n
\n<\/span>
\n<\/span>The general problem with this is that the distinction is based on lexical considerations, rather than structural reasoning. I will use the terms lexical syntax colouring<\/em><\/strong> for what is currently done and structural syntax colouring<\/em><\/strong> for what it should be.<\/p>\n
\n
\n<\/span>In my view, that purpose of syntax colouring is to make source code more readable to programmers. The way it can achieve this, is by making the code structure more obvious.<\/p>\n
\n<\/span>
\nStructural syntax colouring would use colour much more explicitly to emphasise the logical structure of the code, instead of the lexical structure. Interesting structural tasks are:<\/p>\n
\n<\/span>\u2022 separating comments from code
\n<\/span>\u2022 separating elements of a class (fields, constructors, methods)<\/p>\n
\nSignatures should stand out from the rest of the text.
\n<\/em><\/span>
\n<\/span>\u2022 highlight field definitions<\/p>\n
\n<\/span>in characteristics. This should pointed out by different appearance.<\/em><\/span><\/p>\n
\n<\/span>belonging to the control structure, and the embedded block. Highlighting<\/em><\/span>
\n<\/span>should colour the control structure keyword and associated parenthesis.<\/em><\/span><\/p>\n
\nshould be immediately visually obvious.<\/em><\/span><\/p>\n
\n<\/span>
\n<\/strong><\/span>![\"new](\"http:\/\/www.bluej.org\/mrt\/wp-content\/uploads\/2006\/07\/_Users_mik_Sites_iblog_B2002791029_C1916402003_E2024643120_Media_code-new.gif\")
\n
\n<\/strong><\/span>Here, I have used background colour to make method definitions stand out. Coloured bars on the right distinguish field definitions, constructors, and methods. Further, public and private methods should be distinguished (not shown here).<\/p>\n
\n<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"