Why isn't rich code formatting more common?

Question

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
begin
  DoStuff();
end.

it could look something like this:

Procedure ResolveCollisions

Performs a posteriori collision resolution through spatial partitioning algorithm

Parameters

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Local Variables

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

    DoStuff();

---

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?

Answer 1

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.

Answer 2

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)

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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:

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).

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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?

Answer 14

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"