I must say that I'm appalled at the code I see. Because all this code suffers the same failings, I conclude it's not a sporadic problem. Apparently all these programmers have copied each others style and are content with the result: that complex applications require millions of lines of code. And that's not even counting the operating system required.

Sadly, that is not an undesirable result. Bloated code does not just keep programmers employed, but managers and whole companies, internationally. Compact code would be an economic disaster. Because of its savings in team size, development time, storage requirements and maintainance cost.

What's wrong with C programs?

• Some problems are intrinsic to the C language:
  • It has elaborate sytnax. Rules that are supposed to promote correctness, but merely create opportunity for error.
  • It has considerable redundancy. This increases trivial errors that can be detected. And program size.
  • It's strongly typed, with a bewildering variety of types to keep straight. More errors.
  • As an infix language, it encourages nested parentheses. Sometimes to a ludicrous extent. They must be counted and balanced.
  • It's never clear how efficiently source will be translated into machine language. Constructs are often chosen because the programmer knows they're efficient. Subroutine calls are expensive.
  • Because of the elaborate compiler, object libraries must be maintained, distributed and linked. The only documentation usually addresses this (apparantly difficult) procedure.
• Others are a matter of style:
  • Code is scattered in a vast heirarchy of files. You can't find a definition unless you already know where it is.
  • Code is indented to indicate nesting. As code is edited and processed, this cue is often lost or incorrect.
  • Sometimes a line of code contains only a parenthesis, or semicolon. This reduces the density of the code, and the difficulty of reading it.
  • There's no documentation. Except for the ubiquitous comments. These interrupt the code, further reducing density, but rarely conveying useful insight.
  • Names tend to be hyphenated. This makes them unique and displays their position in the heirarchy. The significant portion of a name is hard to detect, slow to read.
  • Constants, particularly fields within a word, are named. Even if used, the name rarely provides enough information about the function. And requires continual cross-reference to the definition.
  • Preoccupation with contingencies. In a sense it's admirable to consider all possibilities. But the ones that never occur are never even tested. For example, the only need for software reset is to recover from software problems.
  • Conditional compilation. More constants include or exclude code for particular platforms. More indentation. More difficulty fathoming which code is relevant.
  • Hooks for future enhancements, or abandoned features, are abundant. This is useful only in understanding the programmer's ambitions.
  • It is in a programmer's best interest to exaggerate the complexity of his program.
• Another difficulty is the mindset that code must be portable across platforms and compatible with earlier versions of hardware/software. This is nice, but the cost is incredible. Microsoft has based a whole industry on such compatibility.

Forth