a function available in most word processing programs which reveals the "hidden" formatting codes that govern how text will be displayed and printed in the document being edited. Microsoft, when it created Word for the Mac OS, in keeping with Apple philosophy at the time, refused to allow such codes to be displayed, arguing that doing so would detract from the WYSIWYG nature of the program. To my knowledge, no one has yet calculated the lost productivity stemming from this single decision, and, as of the year 2000, Microsoft has not moved away from their commitment to keep the codes hidden, and therefore an exciting mystery for users everwhere.

Some would argue that the lack of a "show codes" functions in Word actually cuts down on the amount of time workers spend doing crosswords puzzles, since the nature of the puzzle is similar, as are the headaches that ensue for some users.

There is a fairly straightforward reason why Microsoft Word has no "show codes" feature - the Word file format doesn't have codes (in any meaningful fashion) to reveal. Unlike inline document formats - SGML in all its variants, WordPerfect, XYwrite, Locoscript, View for the BBC Micro, RTF, whatever - where formatting is marked by control characters embedded in the text to indicate a format change at that particular point, the native Word format maintains (simplistically described) a complete version of the text without codes, preceded by a separate binary section containing arbitrarily ordered pointers to variously formatted bits of that text.

This is clearly a programming decision for the programmers' benefit, which is not designed to facilitate users' poking around in the innards of the file (you can screw up a Word file completely much more readily than many of the others mentioned); it makes it easier to deal with multiple levels of undo and allows the loathsome "fast save" option (which is a good way of promoting catastrophic data loss) where new bits of the text are just tacked on at the end of the file). Word does have the facility to display non-printing characters - carriage returns, tabs, spaces, soft hyphens and the like - which is reasonably useful - but will not and cannot show an annotated, non-WYSIWYG version of the text with interspersed character/paragraph/page formatting codes. As to whether it's a good programming decision ...

Log in or register to write something here or to contact authors.