DOCSLIB.ORG

Ada 95 Quality and Style: Guidelines for Professional Programmers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Ada 95 Quality and Style: Guidelines for Professional Programmers Department of Defense Ada Joint Program Office SPC-94093-CMC Version 01.00.10 October 1995 Ada 95 Quality and Style: Guidelines for Professional Programmers SPC-94093-CMC Version 01.00.10 October 1995 Prepared for the Department of Defense Ada Joint Program Office Produced by the SOFTWARE PRODUCTIVITY CONSORTIUM SPC Building 2214 Rock Hill Road Herndon, Virginia 22070 Copyright 1995, Software Productivity Consortium, Herndon, Virginia. This document can be copied and distributed without fee in the U.S., or internationally. This is made possible under the terms of the DoD Ada Joint Program Office’s royalty-free, worldwide, non-exclusive, irrevocable license for unlimited use of this material. This material is based in part upon work sponsored by the DoD Ada Joint Program Office under Advanced Research Projects Agency Grant #MDA972-92-J-1018. The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be inferred. The name Software Productivity Consortium shall not be used in advertising or publicity pertaining to this material or otherwise without the prior written permission of Software Productivity Consortium, Inc. SOFTWARE PRODUCTIVITY CONSORTIUM, INC. MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE OR ABOUT ANY OTHER MATTER, AND THIS MATERIAL IS PROVIDED WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. _________________________ Ada-ASSURED is a trademark of GrammaTech, Inc. ADARTS SM is a service mark of the Software Productivity Consortium Limited Partnership. IBM is a registered trademark of International Business Machines Corporation. VAX is a registered trademark of Digital Equipment Corporation. The X Window System is a trademark of the Massachusetts Institute of Technology. Other product names, or names of platforms referenced herein may be trademarks or registered trademarks of their respective companies, and they are used for identification purposes only. PREFACE PURPOSE * The purpose of Ada 95 Quality and Style: Guidelines for Professional Programmers is to help computer professionals produce better Ada programs by identifying a set of stylistic guidelines that will directly impact the quality of their Ada 95 programs. This style guide is not intended to replace the Ada Reference Manual (1995) or Rationale (1995) or to serve as a tutorial for the Ada 95 programming language. Furthermore, this book is not intended to be a guide for transitioning from Ada 83 to Ada 95. The reader is encouraged to consult the References for sources on these related topics. The style guide is divided into chapters that map to the major decisions that each programmer addresses when creating high-quality, reliable, reusable, and portable Ada software. Some overlap exists in the chapters because not all programming decisions can be made independently. Individual chapters address source code presentation, readability, program structure, programming practice, concurrency, portability, reusability, performance, and a new chapter on object-oriented features. Each chapter is divided into guidelines, using a format that supports wide usage because its content is both prescriptive and tailorable. Each guideline consists of a concise statement of the principles that should be followed and a rationale explaining why the guideline is important. The guidelines also provide usage examples, in addition to possible exceptions to applying the guidelines. Many of the guidelines are specific enough to be adopted as corporate or project programming standards. Others require a managerial decision on a particular instantiation before they can be used as standards. In such cases, a sample instantiation is presented and used throughout the examples. BACKGROUND The Ada Joint Program Office (AJPO) funded this style guide, which was created by merging a set of guidelines for using Ada 95 with modifications to the original Ada Quality and Style: Guidelines for Professional Programmers, version 02.01.01 (AQ&S 83) (Software Productivity Consortium 1992), developed to support Ada 83. The Ada 95 guidelines are based on the wealth of data available from the Ada 9X Project, the AJPO library, and the Ada community at large. The Software Productivity Consortium’s (Consortium’s) technical staff authored the update and the Advanced Research Projects Agency (ARPA) participated in the update effort. The preexisting AQ&S 83 presented a set of guidelines to help the programmer make disciplined use of Ada’s features. In 1992, the Consortium completed the version 2.1 update to the style guide under contract to the AJPO. The AJPO referred to that style guide as “the suggested style guide for all DoD programs.” PUBLIC COMMENT This new style guide is intended to provide a tool for both the novice and the experienced Ada programmer. To meet this objective, the Consortium directly involved both the public and the best available experts from across the Ada community. To ensure this involvement, a three-step process was defined to develop this style guide: develop a draft baseline, conduct public and expert review, and develop a final style guide. The Consortium invites comments on this book to continue enhancing its quality and usefulness. The authors will consider suggestions for current guidelines and areas for future expansion. Examples that highlight particular points are most helpful. * This material is based in part upon work sponsored by the Department of Defense Ada Joint Program Office, through the Advanced Research Projects Agency under Grant #MDA972-92-J-1018. The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be inferred. iii iv Ada 95 QUALITY AND STYLE Electronic copies of this style guide are available for downloading through the Ada Information Clearinghouse (phone: 1(800)232-4211; e-mail: [email protected]). Please direct written comments to: Christine Ausnit Software Productivity Consortium 2214 Rock Hill Road Herndon, VA 22070 e-mail: [email protected] fax: (703) 742-7200 or Kent A. Johnson Software Productivity Consortium 2214 Rock Hill Road Herndon, VA 22070 e-mail: [email protected] fax: (703) 742-7200 Please include your contact information in your comments. AUTHORS AND ACKNOWLEDGMENTS The Consortium wishes to recognize all of the nearly 100 contributors to previous versions of this style guide written to support Ada 83, including its authors, editors, and distinguished reviewers. The contributors to this version of the style guide include the authors, Ms. Christine Ausnit-Hood, Mr. Kent A. Johnson, Mr. Robert G. Pettit, and Mr. Steven B. Opdahl, and the following Distinguished Reviewers, Expert Reviewers, and Technical Advisors. Distinguished Reviewers: Mr. Bill Beckwith, Objective Interface Systems, Inc.; Dr. Norman H. Cohen, IBM TJWatson Research Center; Dr. Robert Dewar, New York University; Dr. Charles B. Engle, Jr., Department of Computer Science, Florida Institute of Technology; Mr. Jay Ferguson, NSA, Department of Defense; Mr. Ken Garlington, Lockheed Martin, Fort Worth Company; Mr. Tim Harrison, ParcPlace-Digitalk Inc.; Mr. Ed Seidewitz, NASA, Goddard Space Flight Center; Mr. S. Tucker Taft, Intermetrics Inc. Expert Reviewers: Mr. Brad Balfour, CACI; Dr. Bryce Bardin, Ada Consulting and Training; Mr. Philip Brashear, CTA Inc.; Dr. Ben Brosgol, Brosgol Consulting and Training; Dr. Michael B. Feldman, Department of Electrical Engineering and Computer Science, George Washington University; Mr. Gil Myers, NOSC ; Mr. Jim Moore, The MITRE Corporation; Ms. Eileen S. Quann, FASTRAK Training, Inc.; Mr. Richard Riehle, AdaWorks; Dr. Tim Teitelbaum, GrammaTech; Dr. Joyce Tokar, Tartan. Technical Advisors: Mr. John Barnes, John Barnes Informatics; Mr. Leslie Dupaix, OO-ALC/TISE, Hill AFB; Mr. Dave Emery, The MITRE Corporation; Mr. Magnus Kempe, Kempe Software CE; Ms. Judy Kerner, The Aerospace Corporation; Mr. Alexander Miethe, CCI; LtCol Pat Lawlis, AFIT/ENG, Wright-Patterson AFB. Thanks to the other contributors who forwarded their comments, guidelines, and examples, including Lisa Chan, Bo Sanden, Wesley Groleau, Terry D. Humphrey, Pascal Leroy, Gilles Demailly, Philippe Kipfer, Tomas Peterson, Ted Baker, Mike Dingas, Willem Treurniet, T. A. Vo, and Dave Weller. Special Thanks to the Following: Ed Seidewitz, Tim Harrison, Bill Beckwith, Ken Garlington, Tucker Taft, Chuck Engle, and Don Reifer for taking time from their busy schedules to attend the Distinguished Reviewer Technical Interchange Meetings. Mike Evans and Dan Hocking from the Army Research Lab for providing electronic meeting support at the Distinguished Reviewer Technical Interchange Meetings. Philip Brashear for rewriting Chapter 10. Mike Feldman and Brian Kallberg for their updates to the dining philosophers problem. John Barnes for providing extracts from his new book. GrammaTech, Inc., who made the new version of their Ada-ASSURED product available. The examples were formatted in whole or in part using their tool. In addition, Bobbie Troy and Mary Mallonee provided technical editing; Debbie Morgan and Lisa Smith provided word processing; and Bobbie Troy provided clean proofing. v vi Ada 95 QUALITY AND STYLE CONTENTS CHAPTER 1 Introduction............................................................................................................................ 1 1.1 ORGANIZATION OF THIS BOOK.................................................................................................
Recommended publications
  • SETL for Internet Data Processing

    SETL for Internet Data Processing

    SETL for Internet Data Processing by David Bacon A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Computer Science New York University January, 2000 Jacob T. Schwartz (Dissertation Advisor) c David Bacon, 1999 Permission to reproduce this work in whole or in part for non-commercial purposes is hereby granted, provided that this notice and the reference http://www.cs.nyu.edu/bacon/phd-thesis/ remain prominently attached to the copied text. Excerpts less than one PostScript page long may be quoted without the requirement to include this notice, but must attach a bibliographic citation that mentions the author’s name, the title and year of this disser- tation, and New York University. For my children ii Acknowledgments First of all, I would like to thank my advisor, Jack Schwartz, for his support and encour- agement. I am also grateful to Ed Schonberg and Robert Dewar for many interesting and helpful discussions, particularly during my early days at NYU. Terry Boult (of Lehigh University) and Richard Wallace have contributed materially to my later work on SETL through grants from the NSF and from ARPA. Finally, I am indebted to my parents, who gave me the strength and will to bring this labor of love to what I hope will be a propitious beginning. iii Preface Colin Broughton, a colleague in Edmonton, Canada, first made me aware of SETL in 1980, when he saw the heavy use I was making of associative tables in SPITBOL for data processing in a protein X-ray crystallography laboratory.
  • Modern Programming Languages CS508 Virtual University of Pakistan

    Modern Programming Languages CS508 Virtual University of Pakistan

    Modern Programming Languages (CS508) VU Modern Programming Languages CS508 Virtual University of Pakistan Leaders in Education Technology 1 © Copyright Virtual University of Pakistan Modern Programming Languages (CS508) VU TABLE of CONTENTS Course Objectives...........................................................................................................................4 Introduction and Historical Background (Lecture 1-8)..............................................................5 Language Evaluation Criterion.....................................................................................................6 Language Evaluation Criterion...................................................................................................15 An Introduction to SNOBOL (Lecture 9-12).............................................................................32 Ada Programming Language: An Introduction (Lecture 13-17).............................................45 LISP Programming Language: An Introduction (Lecture 18-21)...........................................63 PROLOG - Programming in Logic (Lecture 22-26) .................................................................77 Java Programming Language (Lecture 27-30)..........................................................................92 C# Programming Language (Lecture 31-34) ...........................................................................111 PHP – Personal Home Page PHP: Hypertext Preprocessor (Lecture 35-37)........................129 Modern Programming Languages-JavaScript
  • Inf 212 Analysis of Prog. Langs Elements of Imperative Programming Style

    Inf 212 Analysis of Prog. Langs Elements of Imperative Programming Style

    INF 212 ANALYSIS OF PROG. LANGS ELEMENTS OF IMPERATIVE PROGRAMMING STYLE Instructors: Kaj Dreef Copyright © Instructors. Objectives Level up on things that you may already know… ! Machine model of imperative programs ! Structured vs. unstructured control flow ! Assignment ! Variables and names ! Lexical scope and blocks ! Expressions and statements …so to understand existing languages better Imperative Programming 3 Oldest and most popular paradigm ! Fortran, Algol, C, Java … Mirrors computer architecture ! In a von Neumann machine, memory holds instructions and data Control-flow statements ! Conditional and unconditional (GO TO) branches, loops Key operation: assignment ! Side effect: updating state (i.e., memory) of the machine Simplified Machine Model 4 Registers Code Data Stack Program counter Environment Heap pointer Memory Management 5 Registers, Code segment, Program counter ! Ignore registers (for our purposes) and details of instruction set Data segment ! Stack contains data related to block entry/exit ! Heap contains data of varying lifetime ! Environment pointer points to current stack position ■ Block entry: add new activation record to stack ■ Block exit: remove most recent activation record Control Flow 6 Control flow in imperative languages is most often designed to be sequential ! Instructions executed in order they are written ! Some also support concurrent execution (Java) But… Goto in C # include <stdio.h> int main(){ float num,average,sum; int i,n; printf("Maximum no. of inputs: "); scanf("%d",&n); for(i=1;i<=n;++i){
  • Jalopy User's Guide V. 1.9.4

    Jalopy User's Guide V. 1.9.4

    Jalopy - User’s Guide v. 1.9.4 Jalopy - User’s Guide v. 1.9.4 Copyright © 2003-2010 TRIEMAX Software Contents Acknowledgments . vii Introduction . ix PART I Core . 1 CHAPTER 1 Installation . 3 1.1 System requirements . 3 1.2 Prerequisites . 3 1.3 Wizard Installation . 4 1.3.1 Welcome . 4 1.3.2 License Agreement . 5 1.3.3 Installation Features . 5 1.3.4 Online Help System (optional) . 8 1.3.5 Settings Import (optional) . 9 1.3.6 Configure plug-in Defaults . 10 1.3.7 Confirmation . 11 1.3.8 Installation . 12 1.3.9 Finish . 13 1.4 Silent Installation . 14 1.5 Manual Installation . 16 CHAPTER 2 Configuration . 17 2.1 Overview . 17 2.1.1 Preferences GUI . 18 2.1.2 Settings files . 29 2.2 Global . 29 2.2.1 General . 29 2.2.2 Misc . 32 2.2.3 Auto . 35 2.3 File Types . 36 2.3.1 File types . 36 2.3.2 File extensions . 37 2.4 Environment . 38 2.4.1 Custom variables . 38 2.4.2 System variables . 40 2.4.3 Local variables . 41 2.4.4 Usage . 42 2.4.5 Date/Time . 44 2.5 Exclusions . 44 2.5.1 Exclusion patterns . 45 2.6 Messages . 46 2.6.1 Categories . 47 2.6.2 Logging . 48 2.6.3 Misc . 49 2.7 Repository . 49 2.7.1 Searching the repository . 50 2.7.2 Displaying info about the repository . 50 2.7.3 Adding libraries to the repository . 50 2.7.4 Removing the repository .
  • C Style and Coding Standards

    C Style and Coding Standards

    -- -- -1- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems ABSTRACT This document describes a set of coding standards and recommendations for programs written in the C language at AT&T and Sun Microsystems. The purpose of having these standards is to facilitate sharing of each other’s code, as well as to enable construction of tools (e.g., editors, formatters). Through the use of these tools, programmers will be helped in the development of their programs. This document is based on a similar document written by L.W. Cannon, R.A. Elliott, L.W. Kirchhoff, J.H. Miller, J.M. Milner, R.W. Mitze, E.P. Schan, N.O. Whittington at Bell Labs. -- -- -2- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems 1. Introduction The scope of this document is the coding style used at AT&T and Sun in writing C programs. A common coding style makes it easier for several people to cooperate in the development of the same program. Using uniform coding style to develop systems will improve readability and facilitate maintenance. In addition, it will enable the construction of tools that incorporate knowledge of these standards to help programmers in the development of programs. For certain style issues, such as the number of spaces used for indentation and the format of variable declarations, no clear consensus exists. In these cases, we have documented the various styles that are most frequently used. We strongly recommend, however, that within a particular project, and certainly within a package or module, only one style be employed.
  • Preconditions/Postconditions Author: Robert Dewar Abstract: Ada Gem

    Preconditions/Postconditions Author: Robert Dewar Abstract: Ada Gem

    Gem #31: preconditions/postconditions Author: Robert Dewar Abstract: Ada Gem #31 — The notion of preconditions and postconditions is an old one. A precondition is a condition that must be true before a section of code is executed, and a postcondition is a condition that must be true after the section of code is executed. Let’s get started… The notion of preconditions and postconditions is an old one. A precondition is a condition that must be true before a section of code is executed, and a postcondition is a condition that must be true after the section of code is executed. In the context we are talking about here, the section of code will always be a subprogram. Preconditions are conditions that must be guaranteed by the caller before the call, and postconditions are results guaranteed by the subprogram code itself. It is possible, using pragma Assert (as defined in Ada 2005, and as implemented in all versions of GNAT), to approximate run-time checks corresponding to preconditions and postconditions by placing assertion pragmas in the body of the subprogram, but there are several problems with that approach: 1. The assertions are not visible in the spec, and preconditions and postconditions are logically a part of (in fact, an important part of) the spec. 2. Postconditions have to be repeated at every exit point. 3. Postconditions often refer to the original value of a parameter on entry or the result of a function, and there is no easy way to do that in an assertion. The latest versions of GNAT implement two pragmas, Precondition and Postcondition, that deal with all three problems in a convenient way.
  • Understanding Programming Languages

    Understanding Programming Languages

    Understanding Programming Languages M. Ben-Ari Weizmann Institute of Science Originally published by John Wiley & Sons, Chichester, 1996. Copyright °c 2006 by M. Ben-Ari. You may download, display and print one copy for your personal use in non-commercial academic research and teaching. Instructors in non-commerical academic institutions may make one copy for each student in his/her class. All other rights reserved. In particular, posting this document on web sites is prohibited without the express permission of the author. Contents Preface xi I Introduction to Programming Languages 1 1 What Are Programming Languages? 2 1.1 The wrong question . 2 1.2 Imperative languages . 4 1.3 Data-oriented languages . 7 1.4 Object-oriented languages . 11 1.5 Non-imperative languages . 12 1.6 Standardization . 13 1.7 Computer architecture . 13 1.8 * Computability . 16 1.9 Exercises . 17 2 Elements of Programming Languages 18 2.1 Syntax . 18 2.2 * Semantics . 20 2.3 Data . 21 2.4 The assignment statement . 22 2.5 Type checking . 23 2.6 Control statements . 24 2.7 Subprograms . 24 2.8 Modules . 25 2.9 Exercises . 26 v Contents vi 3 Programming Environments 27 3.1 Editor . 28 3.2 Compiler . 28 3.3 Librarian . 30 3.4 Linker . 31 3.5 Loader . 32 3.6 Debugger . 32 3.7 Profiler . 33 3.8 Testing tools . 33 3.9 Configuration tools . 34 3.10 Interpreters . 34 3.11 The Java model . 35 3.12 Exercises . 37 II Essential Concepts 38 4 Elementary Data Types 39 4.1 Integer types .
  • CWI Scanprofile/PDF/300

    CWI Scanprofile/PDF/300

    Centrum voor Wiskunde en lnformatica Centre for Mathematics and Computer Science L.G.L.T. Meertens, S. Pemberton An implementation of the B programming language Department of Computer Science Note CS-N8406 June Biblioiiie.:;I( ~'~'l'i't'Hm.n<' Wi~f.i;r;de- c11 !nform;:,;i:i.C<a - Ams1errJar11 AN IMPLEMENTATION OF THE B PROGRAMMING LANGUAGE L.G.L.T. MEERTENS, S. PEMBERTON CentPe foP Mathematics and ComputeP Science~ AmstePdam Bis a new programming language designed for personal computing. We describe some of the decisions taken in implementing the language, and the problems involved. Note: B is a working title until the language is finally frozen. Then it will acquire its definitive name. The language is entirely unrelated to the predecessor of C. A version of this paper will appear in the proceedings of the Washington USENIX Conference (January 1984). 1982 CR CATEGORIES: 69D44. KEY WORDS & PHRASES: programming language implementation, progrannning envi­ ronments, B. Note CS-N8406 Centre f~r Mathematics and Computer Science P.O. Box 4079, 1009 AB Amsterdam, The Netherlands I The programming language B B is a programming language being designed and implemented at the CWI. It was originally started in 1975 in an attempt to design a language for beginners as a suitable replacement for BASIC. While the emphasis of the project has in the intervening years shifted from "beginners" to "personal computing", the main design objectives have remained the same: · • simplicity; • suitability for conversational use; • availability of tools for structured programming. The design of the language has proceeded iteratively, and the language as it now stands is the third iteration of this process.
  • A Description of One Programmer's Programming Style Revisited

    A Description of One Programmer's Programming Style Revisited

    A Description of One Programmer’s Programming Style Revisited Adam N. Rosenberg 1990 August 1 2001 October 1 ABSTRACT We present the outlook of a programmer at AT&T Bell Labs who has written much code during his eight years there and thirteen years in other places. This document describes the author’s own programming style and what he considers important in generating reli- able, readable, and maintainable code. Since this document is the opinions and prejudices of an individual, it is written in the first person in a conversational tone, and with subjects covered in no particular order. It is intended to be a repository of good questions rather than a source of answers. The author feels that many programmers suffer from gross inattention to detail in writing code. He suggests that clarity and consistency will be rewarded sooner than most people think. A veteran of many languages and operating systems, the author today finds himself using the MS-DOS and UNIXr operating systems and the FORTRAN and C languages. The examples here are all either FORTRAN or C. A decade later the author feels that programming productivity in our “post modern” world has decreased sharply from 1990 to 2000. Many of the reasons for this decline were discussed in the original version of this paper. Our pleasure in prescient prognostication is mitigated by frustration with the “dumbing down” of computing in general. Based on this unhappy downturn of programming education and style, we have added materal (in italics) emphasizing areas of recent concern. The original text and examples (still in regular type) have been left virtually intact.
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0

    Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0

    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
  • Ada Distilled by Richard Riehle

    Ada Distilled by Richard Riehle

    Ada Distilled by Richard Riehle An Introduction to Ada Programming for Experienced Computer Programmers by Richard Riehle AdaWorks Software Engineering http://www.adaworks.com Copyright 2002, AdaWorks Software Engineering Public Edition. Permission to copy if AdaWorks is acknowledged in copies Version: July 2003 Page 1 of 113 Ada Distilled by Richard Riehle Acknowledgments There are always a lot of people involved in the creation of any book, even one as small and modest as this one. Those who have contributed to the best features of this book include my students at Naval Postgraduate School, Mr. Michael Berenato of Computer Sciences Corporation, Mr. Ed Colbert of Absolute Software, and many students from Lockheed-Martin Corporation, Computer Sciences Corporation, British Aerospace, various branches of the uniformed services, to name a few. I also owe a special thanks to Dr. Ben Brosgol, Dr. Robert Dewar, Mr. Mark Gerhardt, and Dr. Mantak Shing for what I have learned from them. Also thanks to the contributors to comp.lang.ada Usenet forum and the Team_Ada Listserve. Phil Thornley deserves extra credit for his detailed reading of the manuscript and many corrections. Special thanks goes to Ed Colbert for his careful study of some of my program examples. He is one of those people who can spot a program error at fifty paces. Using this unique skill, Ed brought many errors, some big and some small, to my attention. Also thanks to more recent input from Phil Thornley and Adrian Hoe. Any other errors are strictly mine. Any mistakes in wording, spelling, or facts are mine and mine alone.
  • DSS: C/C++ Programming Style Guidelines

    DSS: C/C++ Programming Style Guidelines

    C/C++ Programming Style Guidelines C/C++ Programming Style Guidelines Table of Contents Introduction File Contents File Format Choosing Meaningful Names Comments Syntax and Language Issues Conclusion Appendix A. Review Checklist References De gustibus non est disputandum. Introduction This document contains the guidelines for writing C/C++ code for Dynamic Software Solutions. The point of a style guide is to greater uniformity in the appearance of source code. The benefit is enhanced readability and hence maintainability for the code. Wherever possible, we adopt stylistic conventions that have been proved to contribute positively to readability and/or maintainability. Before code can be considered for peer review the author must check that it adheres to these guidelines. This may be considered a prerequisite for the review process. A checklist is provided at the end of this document to aid in validating the source code's style. Where code fails to adhere to the conventions prescribed here may be considered a defect during the review process. If you have not already, please study Code Complete by Steve McConnell. This book provides a detailed discussion on all things related to building software systems. It also includes references to statistical studies on many of the stylistic elements that affect program maintainability. Another valuable source of solid programming practice tips is The Practice of Programming by Brian W. Kernighan and Rob Pike. Scott Meyers' books, Effective C++ and More Effective C++ should be considered required reading for any C++ programmer. And what person would be considered complete without having read The Elements of Style by Strunk and White? References The C++ Programming Language, Bjarne Stroustrup, 0-201-88954-4, Addison-Wesley, 1997.