I was reading Code Complete and in the chapter on layout and style, he was predicting that code editors would use some sort of rich text formatting. That means, instead of code looking like this

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision

it could look something like this:

Procedure ResolveCollisions

Performs a posteriori collision resolution through spatial partitioning algorithm


  • CurrentMap : SpriteContext
  • PotentialColliders : SpriteList

Local Variables

  • Collider : Sprite
  • Collidee : Sprite
  • Collision : SpriteCollision

I've seen syntax coloring and highlighting and even parentheses coloring, but nothing that looked like this in actual code. I was wondering if this sort of thing actually ever existed, or perhaps if it was decided that it didn't have enough benefit or that it was an entirely bad idea.

Have any of you seen richly-formatted code like this before, or know if the idea was ever considered and eventually rejected?


14 Answers 14


There is no technical reason that you couldn't. If text editors can do syntax highlighting, they could just as easily change other aspects of the display to highlight code.

However, it's one thing to have whatever is being typed change colors as the editor figures out what you are typing. Having the text suddenly change sizes and jump around while you are typing would get really obnoxious.

However, for a 'static' code display, you could easily beautify source code. For example take any halfway decent source->html converter, and add whatever font sizes and styles you like to the stylesheets, and you'll have rich formatted code.


Simple reason: editor/tool independence.

Once you make you code "rich" -- it will be tied to the editor that you used -- or to the ones that can understand rich code. All other editors that can't handle richness will show gibberish.

In the same vein, rich code wouldn't play well with diff tools. For example, if you just changed some formatting, the diff will show a difference, but it is not even a difference you're least concerned with.

And what about version control? How would you tell it to ignore all the changes in formatting and see files as modified only when there is some "real" change.

Finally I guess, the whole point of rich code is readability -- and for that, I think better (and more) comments, logical identifier names, and consistent indentation will suffice.

In essence, the programming text is best handled as a plain text -- what you're seeing is what the reality. (which is also in line with the Pythonic idea of explicit better than implicit)

  • 28
    That's not necessarily true. If editors can do syntax highlighting, it sure can do syntax "bolding" or syntax "font-sizing", etc. Commented Dec 3, 2011 at 6:43
  • 4
    Emacs can be configured to do this, but IMO changing the font size would be a waste of screen space. Commented Dec 3, 2011 at 6:49
  • 4
    If the author had to do the formatting manually, it would be a waste of time. Clearly, the text editor would automatically do it, or maybe you could use a stylesheet of sorts. Commented Dec 3, 2011 at 21:58
  • 7
    @greegit: editors don't leave color information in the source files when they are done with them, they don't have to leave other formatting marks, they can regenerate them on demand. There is no fundamental difference between syntax highlighting and syntax formatting. If tools can make spiffy class diagrams and UML diagrams from source code automatically, a tool sure could bold stuff from time to time. Commented Dec 4, 2011 at 20:01
  • 9
    This answer sure has a lot of upvotes for being incorrect.
    – Jordan
    Commented Dec 4, 2011 at 22:50

Perhaps richly formatted code has not caught on because it is not such a cool idea. Personally, I do not like what I see in the example you provided. I use syntax coloring and highlighting, but that formatting is too wrought, and it deviates too much from the way I am used to seeing and writing code.


Why does it not exist? There isn't the demand/need for it.

Current editors are able to satisfy the needs of programmers with syntax highlighting and some other minor stylistic options. Is that not "rich text" already?

  • 7
    +1 For no demand. I would hate to code like that. Looks like I'm typing up that TPS report in Word, not writing code.
    – user7007
    Commented Dec 4, 2011 at 17:21
  • 1
    @Glenn Nelson: I agree. I avoid Word even for typing normal documents if I can (I use LaTeX instead). I like syntax highlighting but rich code formatting would really feel intrusive to me.
    – Giorgio
    Commented May 20, 2012 at 10:43

This already exists for LaTeX in AucTeX mode for Emacs. Section titles are larger in size, sub and superscripts are resized appropriately and you can even have little previews of math (and possibly other environments like Algorithmic).

This is fine for LaTeX because the mapping from the code to the output is usually much more straightforward than in other programs; I think I would not like that at all for more general-purpose languages.

Another thing Emacs can do is replace symbols like -> and forall with and respectively in Haskell. There is little reason this sort of thing can't be extended to doing formatting like you're suggesting except that it isn't necessary at all in Haskell.


Some time ago, I asked this question on code formatting, asking whether programmers would want their code formatted as they typed.

My question only addressed the indentation aspect of formatting, but some answers may well apply to code formatting in general. The overall sentiment in the answers suggest that programmers are opposed to losing absolute control of the way their code is represented.

My personal experience has been quite different. Though I normally use publicly available tools, sometimes I need to write XSLT in my own bespoke editor. This editor formats code as I type by indenting the left-margin so I have no issues with unwanted whitespace (significant in XSLT) and allows my code to word-wrap and yet still maintain formatting. I find the experience quite natural, formatting style is controlled by the context and position of line-feeds alone (the experience is especially rewarding when using touch-sensitive input devices).

If the XSLT is not well-balanced, the formatting actually helps show where the problem lies. It took a while to adjust to code shifting horizontally as you type but it isn't a distraction for me any more. I did however find that formatting features that affected the vertical spacing of my XSLT rendered the editor just about unusable, so I've disabled these.

To go back to your question, I think the reason why rich code formatting is not more common is just that it takes a long time for perceptions to change in the programming world. Its time will come, possibly coinciding with the time when code editing is done predominantly without a keyboard.


Also in more than a few languages (Haskell, Ruby, Python, Erlang, CoffeeScript a few others) indentation is important. So if you are changing font sizes it could get very hard to figure out.

Mostly its tradition. I have been programming professionally for almost 20 years and I suspect it would drive me nuts. I write books in Emacs or VI with docbook, so I am not a WYSIWIG fan


Knuth’s CWEB does this, but it only works for C/C++ and Pascal. — You should take a look at it though… it’s quite neat. There are two programs: ctangle and cweave which combine/separate CWEB files into TeX and C respectively.

  • 1
    noweb works with nearly any possible language. And there are numerous specialised literate programming systems available for many other languages as well (lhs and alike). Some languages had a typesetting capability out of the box from early 1960s - see en.wikipedia.org/wiki/Stropping_(programming)
    – SK-logic
    Commented Dec 4, 2011 at 12:43
  • 3
    @SK-logic - Arrgh, please don't remind me of the horror that is literate programming. Turning every quick code review into a tedious and lengthy document review, critiquing every last turn of phrase and misplaced comma. Why some parts of the defence industry thought this was a good idea I will never know. I don't think that WYSIWYG editors would have made it any better.
    – Mark Booth
    Commented Dec 5, 2011 at 11:39
  • @Mark Booth, anything can turn into a horror if done wrong. Literate programming is a great tool when combined with a proper discipline. I've got no idea how I'd be able to annotate my code with complex TeX-formatted formulas, plots and graphs without a literate programming tool. And code is not going to be any more readable and maintainable without such annotations.
    – SK-logic
    Commented Dec 5, 2011 at 11:57

Have any of you seen richly-formatted code like this before, or know if the idea was ever considered and eventually rejected?

Sure. Xcode supports styles beyond simple coloring for different syntax:

source code with styled text

It's been a long time since I used it, but I think Metrowerks CodeWarrior supported styled text too, and that was 10+ years ago.

You don't want to go overboard with the styles, though -- any text, source code or otherwise, can be harder to read when the styles vary too much. In particular, I think mixing sizes is distracting, and anything that causes columns not to line up is annoying. There's a reason most programmers still use monospaced fonts.

A different question is whether styled text should be used as part of the language syntax itself. For example, should the compiler use the fact that some text is styled a certain way to determine that the text is a function declaration? That might sound crazy at first, but languages like Python and Fortran already use indentation as syntax. Nevertheless, I think it's more likely that we'll continue to see style driven by syntax rather than the other way around. There are a lot of benefits that come from being able to use plain text (simpler compilers, platform independence, programmer preferences), and other traditions have evolved to make code readable in the absence of styles (indentation, blank lines, marker characters, and editor features like code folding and navigation menus).


I think that rich formatting of source code is not very popular because it is intended for information input, where structure and meaning is far more important (and easier to type as well). Fontification, extra special symbols and white spaces just add unnecessary visual noise. It might be appropriate for generated documentation though.

There are never ending flame war about the same topic in typesetting world between those who prefer WYSIWYG editors (like MS Word) and systems like TeX (LaTeX).

In general, there is no definitive answer. It all depends on tools, use cases and personal preferences.


Tools such as Doxygen or JavaDoc already perfom rich text code formatting. They add code hypertext as well for browsing purpose. You don't need to insert special tags for basic formatting.

This is not WYSIWYG though.


I'm afraid to say that this does exist.

In the past I've worked on some Centura (also known as Gupta or SQL/Windows - an old "4GL") code. It wasn't really possible to edit Centura code in a standard editor like notepad do to the extreme level of formatting required.

Although it may seem like it would be a good idea to have a source file formatted like this, I found developing to be quite restrictive and painful.

Additionally, the formatting often caused problems when merging in source control.


In addition to the other answers, I'd like to point out that besides the technical difficulties of using rich formatting, it is also object of personal preference.

If you edit plain text, you can choose the fonts and colors you like, and they are set automatically. If you'd edit rich text, what if you just don't like particular colors and fonts which are set manually?

  • 1
    I don't think this is true. I'm pretty sure if programmers used rich text, there would be a generator that made some sort of semantic markup that describes the structure of the program, and then a user-customizable stylesheet that contains the font and color information. Commented Dec 19, 2011 at 16:40
  • @PeterOlson then you won't be able to read programs without your stylesheet, since you simply won't recognize designation of text strings. This means nobody could show or write anything when meeting in person. On the contrary, presently fonts and colors are fully optional and interchangeable without any harm to meaning.
    – corvinus
    Commented Dec 19, 2011 at 21:17

I think this is because nobody yet separated code reading and code writing. At least it doesn't become mainstream. Sometimes you have to read code you touched long ago or code created by other developers. You will probably have to spend much time until ready for changing a single byte in this source. This could be "read" mode that can do whatever is needed for easier understanding (font size, reformatting, sub-script, super-script etc). When you're ready, the editor can switch to "write" mode and be less restrictive and more obeying "the rule of least surprise"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.