Common Sense C - Advice and Warnings for C and C++ Programmers:Managing C and C++ Development






Common Sense C - Advice & Warnings for C and C++ Programmers

by Paul Conte

29th Street Press

ISBN: 1882419006   Pub Date: 10/01/92  




Previous Table of Contents Next The Evolution of Standards Standards shouldn’t be frozen in time. A “standard” that changes weekly isn’t much use, but over time good standards evolve as you discover more effective approaches. Some newly discovered approaches may be improvements in lexical style, but the main improvements will be in the reuse of macro, function, and class libraries. As these libraries grow and improve, old methods may be replaced by better ones and the standards should be modified to reflect the changes. Evolution of the standards is easier than evolution of existing code. This is the place for good editors and translation tools. Most programming editors today provide both a search-and-replace feature that supports advanced “regular expression” pattern matching, as well as an “extension” (or “macro”) language for writing editing functions or scripts. Together these facilities allow you to make file-wide revisions more easily. For quick standalone translations, a language like Awk is an easy-to-use, powerful tool. Awk provides regular expression pattern matching, dynamic table handling and simplified I/O, and it uses a syntax similar to C, so it’s an ideal “workbench” tool for C programming. Changing code to satisfy evolving standards is only one reason to use the best programming editor you can find for C programming. Among the capabilities you can expect from a good editor: multiple files and windows, mouse-driven text selection and file positioning, auto-indenting of C source code, block indent and unindent, finding matching delimiters, one- and two-keystroke “skeleton” code expansion, compiler execution from within the editor, pop-up display of compiler errors, and point-and-shoot navigation to the source of errors. With a good editor, it’s so easy to manipulate text that it’s not a burden to pay careful attention to programming standards, especially ones that deal with lexical style. By contrast, “dumb terminal” and line-oriented editors, or editors without mouse and window support or an extension language, are poor choices to encourage programmers to “polish” code. No Train, No Gain C and C++ aren’t for amateurs. They are powerful and can be dangerous. Programmers should have a solid background in programming methods and some experience writing “throw-away” programs in C or C++ before attempting their first mission-critical applications. Don’t learn C by writing a production program! As I mentioned in Chapter 1, a common question is whether to learn C or C++ first. I suggested the best answer may be “neither” — learn Pascal or another “cleaner” language first. This advice is especially important for programmers who have only worked in COBOL, RPG, or other older business languages. C introduces many new concepts, such as data types, scoped variables, static and automatic storage, functions, and dynamic data structures. Unfortunately, in C these concepts are intermixed with machine-level constructs so they are harder to learn and more error-prone than with some other languages. Learning the concepts first in a language like Pascal provides a much better foundation with which to tackle C. In addition, it sets the right frame of mind for avoiding some of the common C idioms that are poor programming practices. Another language that provides a more rational introduction to C is Awk. Awk has a C-like syntax (it was derived from C), but eliminates some troublesome C elements — most importantly, pointers — and adds easy-to-use, powerful, built-in facilities for string and table handling. One nice aspect of learning Awk, in addition to making the transition to C, is that even when C is used for production programs, Awk provides an excellent “workbench” tool. Similar advice applies to learning C++ object-oriented programming (OOP) facilities. Learning a language like Smalltalk or Actor, which was designed from the start to support OOP, provides a better introduction than simultaneously trying to learn OOP concepts and C++’s often arcane implementation. To begin C programming, it’s probably advisable to start with a C++ compiler and treat it as “a better C.” C++ is rapidly replacing C, and it makes sense to learn the newer C++ facilities (e.g., new instead of malloc(), and the Streams class library instead of the standard C I/O library). On the other hand, a programmer new to C should write several production programs before trying to write any non-trivial C++ classes. Before a programmer can write complex classes well, he or she needs a deep understanding of the issues that arise when classes are used to define new variables or as super-classes from which member data and functions are inherited. And it requires mastery of both OOP concepts and C++ details before a programmer can write classes that will be shared by other programmers and projects. Certainly any programmer wanting to write C++ classes should have read and fully comprehended the principles in C++ Programming Style by Tom Cargill. The Right Tool For the Job A variety of other tools in addition to good editors can make a big difference in C and C++ programming. Some of these tools help with “programming in the small” (working on a single program); others help with “programming in the large” (working on systems that comprise many programs). One set of tools documents or analyzes C or C++ source code. A variety of “pretty printers” can format code and produce cross-reference listings of variables, functions, and classes; flowcharts; and module structure charts. These are especially useful tools for dealing with legacy code that may be poorly laid out and documented. Unfortunately, most formatters do not provide much flexibility in specifying the output’s layout. For new code, you’re better off using a good editor that lets you apply human judgment as you work with the code, so you get easy-to-read displays and listings without needing a separate formatting tool. Code analyzers range from fairly simple “lint” utilities to tools that check code compliance against standards and calculate various measures of code “complexity.” Lint utilities examine C source for constructs that may be acceptable to the compiler but that are likely to be unintentional and incorrect. For example, most lint utilities will report the use of = within conditional expressions. As an example of a standards-checking code analyzer, the CodeCheck product from Abraxus Software will check C source code for both lexical style and specific usage rules. The rules are specified external to the analyzer program and can be modified or extended to meet specific organizational standards. Previous Table of Contents Next Copyright © NEWS/400 Books