Criticism of the C programming language: Difference between revisions

Revision as of 22:58, 21 September 2006

Revision as of 17:09, 22 September 2006

Line 32:

* A [[function prototype]] with an empty parameter list allows any set of parameters, a syntax problem introduced for [[backward compatibility]] with [[The C Programming Language (book)|K&R C]], which lacked prototypes.

* Some questionable choices of operator precedence, as mentioned by Kernighan and Ritchie above, such as <code>==</code> binding more tightly than <code>&</code> and <code>|</code> in expressions like <code>x & 1 == 0</code>.

* The use of the <code>=</code> operator, used in mathematics for equality, to indicate assignment. Ritchie made this syntax design decision consciously, based primarily on the argument that assignment occurs more often than comparison. However, as explained by [[Computer science|computer scientist]] [[Damian Conway]] in his "Seven Deadly Sins of Introductory Programming Language Design": "Many students, when confronted with this operator, become confused as to the nature of assignment and its relationship to equality. […] [A different syntax] seems to evoke less confusion, [because it] reinforces the notion of procedural ''transfer'' of value, rather than transitive ''equality'' of value.".[http://citeseer.ist.psu.edu/mciver96seven.html]

* Similarly, the similarity of the assignment and equality operators (<code>=</code> and <code>==</code>) makes it easy to substitute one for the other, and C's weak type system permits each to be used in the context of the other without a compilation error (although some compilers produce warnings).<ref>For example, the conditional expression <code>if (a=b)</code> is only true if <code>b</code> is not zero.</ref> [http://www.cs.ucr.edu/~nxiao/cs10/errors.htm]

* A lack of [[infix notation|infix]] operators for complex objects, particularly for string operations, making programs which rely heavily on these operations difficult to read. The [[Lisp programming language|Lisp]] language, with no infix operators whatsoever, exhibits this problem to an even greater extent.

* Heavy reliance on punctuation-based symbols even where this is arguably less clear, such as "&&" and "||" instead of "and" and "or," respectively. Some are also confused about the difference between bit-wise operators ("&" and "|") and logical operators ("&&" and "||"), especially since the former can frequently, but not always, be inserted in place of the latter with no change in behavior.

* Unintuitive declaration syntax, particularly for [[Function pointer|function pointers]]. <!-- Note that these Conway quotes do talk about C++, not C --> In the words of language researcher [[Damian Conway]], speaking about the very similar C++ declaration syntax:

<blockquote>

Specifying a type in C++ is made difficult by the fact that some of the components of a declaration (such as the pointer specifier) are prefix operators while others (such as the array specifier) are postfix. These declaration operators are also of varying precedence, necessitating careful bracketing to achieve the desired declaration. Furthermore, if the type ID is to apply to an identifier, this identifier ends up at somewhere between these operators, and is therefore obscured in even moderately complicated examples (see Appendix A for instance). The result is that the clarity of such declarations is greatly diminished.