Structured Programming with Go to Statements DONALD E. KNUTH

Total Page:16

File Type:pdf, Size:1020Kb

Structured Programming with Go to Statements DONALD E. KNUTH Structured Programming with go to Statements DONALD E. KNUTH Stanford University, Stanford, California 9~S05 A consideration of several different examples sheds new light on the problem of ereat- ing reliable, well-structured programs that behave efficiently. This study focuses largely on two issues: (a) improved syntax for iterations and error exits, making it possible to write a larger class of programs clearly and efficiently without go to state- ments; (b) a methodology of program design, beginning with readable and correct, but possibly inefficient programs that are systematically transformed if necessary into efficient and correct, but possibly less readable code. The discussion brings out op- posing points of view about whether or not go to statements should be abolished; some merit is found on both sides of this question. Fina!ly, an attempt is made to define the true nature of structured programming, and to recommend fruitful direc- tions for further study. Keywords and phrases: structured programming, go to statements, language design, event indicators, recursion, Boolean variables, iteration, optimization of programs, program transformations, program manipulation systems searching, Quieksort, efficiency CR categories: 4.0, 4.10, 4.20, 5.20, 5.5, 6.1 (5.23, 5.24, 5.25, 5.27) You may go when you will go, And I will stay behind. --Edna St. Vincent Millay [66] Most likely you go your way and I'll go mine. --Song title by Bob Dylan [33] Do you suffer from painful elimination? --Advertisement, J. B. Williams Co. INTRODUCTION change your life. The reasons for this revolu- tion and its future prospects have been aptly A revolution is taking place in the way we described by E. W. Dijkstra in his 1972 Tur- write programs and teach programming, be- ing Award Lecture, "The Humble Program- cause we are beginning to understand the mer" [27l. associated mental processes more deeply. It As we experience this revolution, each of is impossible to read the recent book Struc- us naturally is developing strong feelings one tured programming [17; 55] without having it way or the other, as we agree or disagree This research was supported in part by the Na- with the revolutionary leaders. I must admit tional Science Foundation under grant number GJ 36473X, and by IBM Corporation. to being a nomhumble programmer, egotisti- Copyright (~) 1974, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted, provided that ACM's copyright notice is given and that reference is made to this publication, to its date of issue, and to the fact that reprint- ing privileges were granted by permission of the Association for Computing Machinery. Computing Surveys, V?L 6, No. 4, Dee,ember 1974 262 , Donald E. Knuth CONTENTS eal enough to believe that my own opinions of the current treads are not a waste of the reader's time. Therefore I want to express in this article several iof the things that struck me most forcefully as I have been thinking about structured programming during the last year; several of my blind spots were re- INTRODUCTION moved as I ivas learning these things, and I 1. ELIMINATION OF so to STATEMENTS hope I can convey some of my excitement to Historical Background A Searching Example the reader. Hardly any of the ideas I will Efficiency discuss are my own; they are nearly all the Error Exits work of others, but perhaps I may be pre- Subscript Checking Hash Coding senting them in a new light. I write this Text Scanning article in the first person to emphasize the A Confession fact that what I'm saying is just one man's Tree Searching Systematic Elimination opinion; I don't expect to persuade everyone Event Indicators that my present views are correct. Comparison of Features Before beginning a more technical discus- Simple Iterations 2. INTRODUCTION OF so to STATEMENTS sion. I should confess that the title of this Recursion Elimination article was chosen primarily to generate Program Manipulation Systems attention. There are doubtless some readers Reeursion vs. Iteration Boolean Variable Elimination who are convinced that abolition of go to Coroutines statements is merely a fad. and they may see Quicksort : A Digression Axiomatics of Jumps this title and think, "Aha! Knuth is rehabili- Reduction of Complication tating the go to statement, and we can go 3. CONCLUSIONS back to our old ways of programming Structured Programming With go to Statements again." Another class of readers will see the Efficiency heretical title and think, "When are die- The Future hards like Knuth going to get with it?" I ACKNOWLEDGMENTS APPENDIX hope that both classes of people will read on BIBLIOGRAPHY and discover that what I am really doing is striving for a reasonably well balanced view- point about the proper role of go to state- ments. I argue for the elimination of go to's in certain cases, and for their introduction in others. I believe that by presenting such a view I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!" [29]. In other words, it, seems that fanatical advocates of the New Pro- gramming are going overboard in their strict enforcement of morality and purity in programs. Sooner or later people are going to find that their beautifully-structured Computing Surveys, Vol. 6, No. 4, December 1974 Structured Programming with go to Sta~ment~ * 263 ! programs are running at only half the speed we also hear complaints about floating-point --or worse--of the dirty old programs they calculations, global variables, semaphores, used to write, and they will mistakenly blame pointer variables, and even assignment the structure instead of recognizing what is statements. Soon we might be restricted to probably the real culprit--the system over- only a dozen or so programs that are suffi- head caused by typical compiler implementa- ciently simple to be allowable; then we will tion of Boolean variables and procedure calls. be almost certain that these programs Then we'll have an unfortunate counter- cannot lead us into any trouble, but of revolution, something like the current rejec- course we won't be able to solve many tion of the "New Mathematics" in reaction problems. to its over-zealous reforms. In the mathematical ease, we know what It may be helpful to consider a further happened: The intuitionists taught the other analogy with mathematics. In 1904, Bert- mathematicians a great deal about deductive rand Russell published his famous paradox methods, while the other mathematicians about the set of all sets which aren't mem- cleaned up the classical methods and even- bers of themselves. This antinomy shook the tually "won" the battle. And a revolution foundations of classical mathematical rea- did, in fact, take place. In the computer soning, since it apparently brought very science case, I imagine that a similar thing simple and ordinary deductive methods into will eventually happen: purists will point the question. The ensuing crisis led to the rise way to clean constructions, and others will of "intuitionist logic", a school of thought find ways to purify their use of floating-point championed especially by the Dutch mathe- arithmetic, pointer variables, assignments, matician, L. E. J. Brouwer; intuitionism etc., so that these classical tools can be used abandoned all deductions that were based on with comparative safety. questionable nonconstructive ideas. For a Of course all analogies break down, includ- while it appeared that intuitionist logic ing this one, especially since I'm not yet would cause a revolution in mathematics. conceited enough to compare myself to But the new approach angered David Hil- David Hilbert. But I think it's an amusing bert, who was perhaps the leading mathema- coincidence that the present programming tician of the time; Hilbert said that "For- revolution is being led by another Dutchman bidding a mathematician to make use of the (although he doesn't have extremist views principle of the excluded middle is like corresponding to Brouwer's); and I do forbidding an astronomer his telescope or a consider assignment statements and pointer boxer the use of his fists." He characterized variables to be among computer science's the intuitionist approach as seeking "to "most valuable treasures!'. save mathematics by throwing overboard At the present time I think we are on the all that is troublesome .... They would chop verge of discovering at last what program- up and mangle the science. If we would ming languages should really be like. I look follow such a reform as they suggest, we forward to seeing many responsible experi- could run the risk of losing a great part of our ments with language design during the next most valuable treasures" [80, pp. 98-99, few years; and my dream is that by 1984 we 148-150, 154-157, 184-185, 268-270]. will see a consensus developing for a really Something a little like this is happening good programming language (or, more likely, in computer science. In the late 1960's we a coherent family of languages). Further- witnessed a "software crisis", which many more, I'm guessing that people will become people thought was paradoxical because so disenchanted with the languages they are programming was supposed to be so easy. now using--even COBOL and FORTrAN-- As a result of the crisis, people are now be- that this new language, UTOPXA84, will have ginning to renounce every feature of pro- a chance to take over.
Recommended publications
  • Preview Objective-C Tutorial (PDF Version)
    Objective-C Objective-C About the Tutorial Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. This is the main programming language used by Apple for the OS X and iOS operating systems and their respective APIs, Cocoa and Cocoa Touch. This reference will take you through simple and practical approach while learning Objective-C Programming language. Audience This reference has been prepared for the beginners to help them understand basic to advanced concepts related to Objective-C Programming languages. Prerequisites Before you start doing practice with various types of examples given in this reference, I'm making an assumption that you are already aware about what is a computer program, and what is a computer programming language? Copyright & Disclaimer © Copyright 2015 by Tutorials Point (I) Pvt. Ltd. All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book can retain a copy for future reference but commercial use of this data is not allowed. Distribution or republishing any content or a part of the content of this e-book in any manner is also not allowed without written consent of the publisher. We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our website or its contents including this tutorial. If you discover any errors on our website or in this tutorial, please notify us at [email protected] ii Objective-C Table of Contents About the Tutorial ..................................................................................................................................
    [Show full text]
  • On Goto Statement in Basic
    On Goto Statement In Basic James spores his coeditor arrest lowse, but ribbony Clarence never perambulating so defenselessly. orFingered ferniest and after sold grapy Barry Jimmy sublime countermarches his microclimates so thwart? envelop snigs opinionatively. Is Skylar mismatched Download On Goto Statement In Basic pdf. Download On Goto Statement In Basic doc. Well before withthe statement recursion, basic, and look understandable like as labe not, usage i learned of. Normal to that precedence include support that the content goto basic;is a goto. back Provided them up by statementthe adjectives basic, novel the anddim knowsstatement exactly with be the in below. basic doesMany not and supported the active for on the goto vba. in theSkip evil the comes error asfrom on movesthe specified to go toworkbook go with thename _versionname_ to see the value home does page. not Activeprovided on byone this is withinsurvey? different Outline if ofa trailingbasic withinspace theor responding value if by thisto. Repaired page? Print in favor statement of code along so we with need recursion: to go with many the methods product. becomeThought of goto is startthousands running of intothe code?more readable Slightly moreand in instances vb. Definitely that runnot onprovided basic program, by a more goto explicit that construct,exponentiation, basic i moreinterpreter about? jump Stay to thatadd youthe workbookwhen goto name. basic commandPrediction gotoor go used, on statement we were basicnot, same moves page to the returns slightly isresults a boolean specific in toworkbook the trademarks name to of. the Day date is of.another Exactly if you what forgot you runa stack on in overflow basic does but misusingnot complete it will code isgenerally the window.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Structured Programming - Retrospect and Prospect Harlan D
    University of Tennessee, Knoxville Trace: Tennessee Research and Creative Exchange The aH rlan D. Mills Collection Science Alliance 11-1986 Structured Programming - Retrospect and Prospect Harlan D. Mills Follow this and additional works at: http://trace.tennessee.edu/utk_harlan Part of the Software Engineering Commons Recommended Citation Mills, Harlan D., "Structured Programming - Retrospect and Prospect" (1986). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/20 This Article is brought to you for free and open access by the Science Alliance at Trace: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The aH rlan D. Mills Collection by an authorized administrator of Trace: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. mJNDAMNTL9JNNEPTS IN SOFTWARE ENGINEERING Structured Programming. Retrospect and Prospect Harlan D. Mills, IBM Corp. Stnuctured program- 2 ' dsger W. Dijkstra's 1969 "Struc- mon wisdom that no sizable program Ste red .tured Programming" articlel could be error-free. After, many sizable ming haxs changed ho w precipitated a decade of intense programs have run a year or more with no programs are written focus on programming techniques that has errors detected. since its introduction fundamentally alteredhumanexpectations and achievements in software devel- Impact of structured programming. two decades ago. opment. These expectations and achievements are However, it still has a Before this decade of intense focus, pro- not universal because of the inertia of lot of potentialfor gramming was regarded as a private, industrial practices. But they are well- lot of fo puzzle-solving activity ofwriting computer enough established to herald fundamental more change.
    [Show full text]
  • Historical Perspective and Further Reading 162.E1
    2.21 Historical Perspective and Further Reading 162.e1 2.21 Historical Perspective and Further Reading Th is section surveys the history of in struction set architectures over time, and we give a short history of programming languages and compilers. ISAs include accumulator architectures, general-purpose register architectures, stack architectures, and a brief history of ARMv7 and the x86. We also review the controversial subjects of high-level-language computer architectures and reduced instruction set computer architectures. Th e history of programming languages includes Fortran, Lisp, Algol, C, Cobol, Pascal, Simula, Smalltalk, C+ + , and Java, and the history of compilers includes the key milestones and the pioneers who achieved them. Accumulator Architectures Hardware was precious in the earliest stored-program computers. Consequently, computer pioneers could not aff ord the number of registers found in today’s architectures. In fact, these architectures had a single register for arithmetic instructions. Since all operations would accumulate in one register, it was called the accumulator , and this style of instruction set is given the same name. For example, accumulator Archaic EDSAC in 1949 had a single accumulator. term for register. On-line Th e three-operand format of RISC-V suggests that a single register is at least two use of it as a synonym for registers shy of our needs. Having the accumulator as both a source operand and “register” is a fairly reliable indication that the user the destination of the operation fi lls part of the shortfall, but it still leaves us one has been around quite a operand short. Th at fi nal operand is found in memory.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Chapter 1 Issues—The Software Crisis
    Chapter 1 Issues—The Software Crisis 1. Introduction to Chapter This chapter describes some of the current issues and problems in system development that are caused The term "software crisis" has been used since the by software—software that is late, is over budget, late 1960s to describe those recurring system devel- and/or does not meet the customers' requirements or opment problems in which software development needs. problems cause the entire system to be late, over Software is the set of instructions that govern the budget, not responsive to the user and/or customer actions of a programmable machine. Software includes requirements, and difficult to use, maintain, and application programs, system software, utility soft- enhance. The late Dr. Winston Royce, in his paper ware, and firmware. Software does not include data, Current Problems [1], emphasized this situation when procedures, people, and documentation. In this tuto- he said in 1991: rial, "software" is synonymous with "computer pro- grams." The construction of new software that is both Because software is invisible, it is difficult to be pleasing to the user/buyer and without latent certain of development progress or of product com- errors is an unexpectedly hard problem. It is pleteness and quality. Software is not governed by the perhaps the most difficult problem in engi- physical laws of nature: there is no equivalent of neering today, and has been recognized as such Ohm's Law, which governs the flow of electricity in a for more than 15 years. It is often referred to as circuit; the laws of aerodynamics, which act to keep an the "software crisis".
    [Show full text]
  • April 17-19, 2018 the 2018 Franklin Institute Laureates the 2018 Franklin Institute AWARDS CONVOCATION APRIL 17–19, 2018
    april 17-19, 2018 The 2018 Franklin Institute Laureates The 2018 Franklin Institute AWARDS CONVOCATION APRIL 17–19, 2018 Welcome to The Franklin Institute Awards, the a range of disciplines. The week culminates in a grand United States’ oldest comprehensive science and medaling ceremony, befitting the distinction of this technology awards program. Each year, the Institute historic awards program. celebrates extraordinary people who are shaping our In this convocation book, you will find a schedule of world through their groundbreaking achievements these events and biographies of our 2018 laureates. in science, engineering, and business. They stand as We invite you to read about each one and to attend modern-day exemplars of our namesake, Benjamin the events to learn even more. Unless noted otherwise, Franklin, whose impact as a statesman, scientist, all events are free, open to the public, and located in inventor, and humanitarian remains unmatched Philadelphia, Pennsylvania. in American history. Along with our laureates, we celebrate his legacy, which has fueled the Institute’s We hope this year’s remarkable class of laureates mission since its inception in 1824. sparks your curiosity as much as they have ours. We look forward to seeing you during The Franklin From sparking a gene editing revolution to saving Institute Awards Week. a technology giant, from making strides toward a unified theory to discovering the flow in everything, from finding clues to climate change deep in our forests to seeing the future in a terahertz wave, and from enabling us to unplug to connecting us with the III world, this year’s Franklin Institute laureates personify the trailblazing spirit so crucial to our future with its many challenges and opportunities.
    [Show full text]
  • Lynn Conway Professor of Electrical Engineering and Computer Science, Emerita University of Michigan, Ann Arbor, MI 48109-2110 [email protected]
    IBM-ACS: Reminiscences and Lessons Learned From a 1960’s Supercomputer Project * Lynn Conway Professor of Electrical Engineering and Computer Science, Emerita University of Michigan, Ann Arbor, MI 48109-2110 [email protected] Abstract. This paper contains reminiscences of my work as a young engineer at IBM- Advanced Computing Systems. I met my colleague Brian Randell during a particularly exciting time there – a time that shaped our later careers in very interesting ways. This paper reflects on those long-ago experiences and the many lessons learned back then. I’m hoping that other ACS veterans will share their memories with us too, and that together we can build ever-clearer images of those heady days. Keywords: IBM, Advanced Computing Systems, supercomputer, computer architecture, system design, project dynamics, design process design, multi-level simulation, superscalar, instruction level parallelism, multiple out-of-order dynamic instruction scheduling, Xerox Palo Alto Research Center, VLSI design. 1 Introduction I was hired by IBM Research right out of graduate school, and soon joined what would become the IBM Advanced Computing Systems project just as it was forming in 1965. In these reflections, I’d like to share glimpses of that amazing project from my perspective as a young impressionable engineer at the time. It was a golden era in computer research, a time when fundamental breakthroughs were being made across a wide front. The well-distilled and highly codified results of that and subsequent work, as contained in today’s modern textbooks, give no clue as to how they came to be. Lost in those texts is all the excitement, the challenge, the confusion, the camaraderie, the chaos and the fun – the feeling of what it was really like to be there – at that frontier, at that time.
    [Show full text]
  • 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){
    [Show full text]
  • 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 .
    [Show full text]
  • 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.
    [Show full text]