Books: A User's Report
Elizabeth Zinkann This month I'll talk about three new books of interest to system administrators. The first deals with the UNIX MAKE utility and also contains Microsoft's and Borland's versions of the tool. The second is on C style and ways to develop a standard. The third book covers SCCS.
Mastering MAKE
A Guide to Building Programs on DOS and UNIX Systems Documentation on the MAKE utility has typically been written for use on the UNIX system. With this book, however, Tondo, Nathanson, and Yount address Microsoft's NMAKE, Borland's MAKE, and the UNIX System's MAKE. In chapters 1 through 4, almost all of the examples are first presented in Microsoft's NMAKE. Where a difference occurs among the other systems, the example is reprinted with the changes not only noted in the example, but also carefully explained, with an emphasis on why the changes were needed. Chapters 5, 6, and 7 are devoted exclusively to the three versions of the MAKE utility. In Mastering MAKE, the authors begin by defining MAKE itself and how it works. After establishing what MAKE really is and demonstrating its syntax rules, they turn to the subjects of hard-coded commands and macros. Chapter 3 provides information about user macros versus predefined macros, pseudotargets, and inference (also known as suffix) rules. The authors also suggest when and why the user should or could employ MAKE. For example, they use the instance of an experienced user creating an empty macro, knowing that it will eventually be needed, versus a beginning user, who will most likely not create the macro until it is needed. Because coverage of advanced topics begins with chapter 4, chapter 3 closes with a section entitled "How Are We Doing?" which presents an example without an explanation. Readers who encounter any difficulty interpreting one or more parts of this example are encouraged to review the pertinent sections. The authors thoughtfully provide some hints at the example's end, noting the sections that cover the different topics. Subsequent chapters of Mastering MAKE combine recursion, environment variables, DOS's use of input files and in-line response files, and also cover error messages. The authors not only explain recursion, but also give several examples of it. They explain what an environment variable is, how to discover any pre-existing environment variables, and how to create and use one of your own. They note that for the two versions of MAKE that apply to DOS, input files and in-line response files can be used, which can condense the often lengthy command lines. Some of the most common error messages and their explanations are also included. The rest of the book explores the different versions of MAKE in detail, examining them separately and also comparing them. This book provides an excellent method of learning MAKE whether you are a DOS or UNIX user. One of the features that I particularly appreciated was a succinct summary at the end of each chapter. Together, the summaries could make a quick reference. For anyone who has ever been confused by MAKE, this book would be an excellent choice.
C Style Standards and Guidelines Most books about C, like most C programmers, concentrate on the writing of original programs rather than on such formal issues as coding, layout design, and commenting. As a result, these issues tend to get dealt with intuitively, haphazardly, or not at all. After all, if your program works and you can understand it, why bother with standards or guidelines? Chances are, however, that your program will someday have to be modified and you probably won't be the one to do it. In that case, your successor will have to be able to read your code, follow your layout, find the names of your variables, and maybe even understand the reason why the program was written. These are some of the topics that David Straker addresses in his book on standards and guidelines. Straker argues that standardization can enhance productivity, quality, maintainability, and understandability, but this is not a book of standards waiting to be put into place. Instead, it explores the elements that comprise a set of standards so that an organization or team can use the standards and guidelines best suited to their purposes. (There is a difference between a standard and a guideline: as the author defines it, a standard is required, whereas a guideline is recommended.) Straker divides the book into five sections: basics, commenting and naming, layout, usage, and implementation. In the basics section, he explores the reasons for implementing coding standards. They can become a tool for the original programmer and for those who will inherit his code. Standards also help those who will have to run present programs under a new system. Instead of generating multiple complaints to the system administrator about what doesn't work, the well-documented program helps solve the problem itself. In the section on commenting and naming, the author provides pointers on naming your identifiers, documenting the program, and separating the comments from the code. To be more specific, documenting a program does not mean "Changed, 5/13/92, EAZ"; instead, you should briefly describe the features you've added, deleted, or modified and tell why, if possible. Similarly, naming identifiers does not mean using a variation of one character for sixteen variables, such as A1, A2, A3, etc.; the variable name should identify what the variable represents. Further, separating comments and code can be as simple as inserting a blank line or with just a little more effort, creating a box that sets the comments apart from the code. Straker's discussion of layout lists the many available options: blocks of code, freestyle, use of white space, uses of tabs versus uses of spaces, blank line spacing, and the questions regarding precedence and placement of opening and closing braces. He points out that despite the great variety of options, some points concerning layout are generally valid. For example, in formatting code, it's important to ensure that a closing brace from a program will not print on the perforated edge of the paper (lest you detach the sides and enter another closing brace only to discover that the program no longer works). In the final sections of the book, Straker addresses usage and implementation. He acknowledges that it is extremely difficult to prescribe when to use which construct. However, the C programming language allows the user to be extremely clever and develop several steps into one. This is not always the most maintainable way to code, since your successor will probably spend a lot of time dissecting this code into one or two simpler steps. For maintenance purposes, it's probably better to keep things simple and straightforward from the beginning. Standards are meaningless, however, if they don't get used, and implementation always depends on the team that is supposed to use the standards. If the standards are accepted, then they will work. However, if they are not supported, they are of no use. In his final section, therefore, Straker examines how standards can be chosen and how to persuade others to use them. The primary audience for this useful and well-written book should be programmers, teams, or quality groups. System administrators who program in C or who participate in quality groups are a subset of this audience. If you have such responsibilities, C Style Standards and Guidelines would be a good choice for your bookshelf.
Source File Management with SCCS Historically, procedures for source file management have developed in response to problems. To demonstrate the need for a coherent system of souce control, Israel Silverberg poses several questions to the reader. One of his questions emphasizes the need for control of source file management. If two teams are working on different changes to the same version of a product, which team's changes become the new version? The Source Code Control System (SCCS) consists of several programs with basic utilities that can create an SCCS file, update an SCCS file with a source file, retrieve a source file from SCCS, and store a source file in an SCCS file. It also has several other utilities which aid in the administration of SCCS files. After introducing the capabilities of SCCS, Silverberg does note that there are other version control systems, including, most notably, RCS (Revision Control System). Silverberg describes the SCCS file as the most important part of SCCS. The SCCS file contains the information necessary to recreate any version of a source file that might be needed. Silverberg then explains one of the more important concepts of SCCS: using delta files to keep copies of each version. The delta file is essential, since it keeps the changes and a copy of the file. The author examines different tables used by SCCS and presents a sample SCCS file. In the next three chapters, Silverberg explores three of the most important SCCS commands: admin, get, and delta. The other commands are discussed in a later chapter. File maintenance is also explored, as well as how to use information provided by the SCCS file. Up to this point, Silverberg's examples have been limited to one source file. However, in building a product, several source files are used. This requires the creation of a source tree. The author shows how to build a source tree, complete with suggestions on how to maintain it. Because most Source Code Control Systems have their own source administrators, system administrators may underestimate the extent of their own involvment with SCCS. In fact, in opening different versions, reopening versions, archiving some of the SCCS files, and sometimes ensuring that all of the SCCS source files are in place before initiating a system backup, the system administrator is usually heavily engaged in the workings of SCCS. Israel Silverberg has produced a practical, easy-to-follow guide to source file management and SCCS for both source administrators and users. While there are several books available on source file management, not many books address SCCS. If your company or organization uses SCCS, this book will assist you in deriving the most from it. If you use another version control system, you might use the book to find out what SCCS can do.
The SCCS Reference Card ASP has published a 5" x 8" reference card on SCCS. It is eight-sided and contains commands, identification keywords, data keywords, and some examples. The examples are short, display the syntax, and explain what the command does. This would be ideal for any source or system administrator.
About the Author
Elizabeth Zinkann has been involved in the UNIX and C environments for the past 10 years. She is currently a UNIX and C consultant, and one of her specialities is UNIX education. In addition to her computer science background, she also has a degree in English.
|