ASTG Coding Standard Recommended Coding Styles For

Total Page：16

File Type：pdf, Size：1020Kb

ASTG Coding Standard Recommended Coding Styles for Software Development in Fortran, C++, Java, and Python Version 1.7 ASTG January 20, 2015 CONTENTS CONTENTS Contents 1 Introduction 1 1.1 Purpose Of Conventions . .1 1.2 Why Use Conventions . .1 1.3 When NOT To Use These Conventions . .1 1.4 When To Use These Conventions . .1 2 Files 2 2.1 Naming Files . .2 2.1.1 Use Class/Module Name For File Name . .2 2.1.2 Extensions . .2 2.2 File Organization . .2 2.2.1 C/C++ Header Files . .3 2.2.2 C/C++ Source Files . .3 2.2.3 Fortran Files . .3 2.2.4 Java Files . .3 2.2.5 Python Files . .4 2.3 C++ Preprocessing . .4 2.3.1 Minimal Includes . .4 2.3.2 Brackets Verses Quotes . .4 2.3.3 Inclusion Protection . .4 2.3.4 Avoid Macros . .5 3 Formatting 5 3.1 Blank Space . .5 3.1.1 Blank Spaces . .5 3.1.2 Indentation . .6 3.2 Lines . .6 3.2.1 Line Length . .6 3.2.2 Line Continuation . .6 3.2.3 Single Blank Lines . .7 3.2.4 Double Blank Lines . .7 3.3 Fortran Free-Format . .7 4 Naming 7 4.1 Expressiveness and Scope . .7 4.2 Abbreviations . .7 4.2.1 Avoid Uncommon Abbreviations . .7 4.2.2 Use Mixed Case Acronyms . .8 4.3 Case and Underscores . .8 4.4 Naming Rules For Identiﬁers . .8 5 Declarations 9 5.1 Routines . .9 5.1.1 Verbs for Routines . .9 5.1.2 Accessors and Mutators . 10 5.1.3 Avoid Global Routines . 10 5.2 Variables and Arguments . 10 5.2.1 Use Nouns . 10 5.2.2 Proximity of Declaration . 10 ii ASTG Coding Standard v1.7 CONTENTS CONTENTS 5.2.3 Initialize Variables . 10 5.2.4 Zero Pointers . 10 5.2.5 One Declaration Per Line . 10 5.2.6 Avoid Literals . 11 5.2.7 Use Booleans for Booleans . 11 5.2.8 Descriptive Namelist Variables . 11 5.2.9 Avoid Global Variables . 11 5.2.10 Use Portable Numeric Types . 11 5.2.11 C++ Casting . 11 5.2.12 Use Argument Modiﬁers . 12 5.2.13 Use “Implicit None” . 12 5.2.14 Automate I/O “Unit Numbers” . 12 5.3 Classes, Modules and Types . 12 5.3.1 Use Pure Block Layout . 12 5.3.2 Fortran Derived Types . 13 5.3.3 Use Lowest Possible Scope . 14 5.3.4 Classes . 15 5.4 Use of External Units . 16 5.4.1 Use Explicit Namespace or Use-Module Items . 16 5.4.2 When To Use Namespaces . 16 5.4.3 Using “using namespace” Clause . 16 6 Structure and Control 17 6.1 Statements . 17 6.1.1 One Statement Per Line . 17 6.1.2 One Operation Per Statement . 17 6.2 Blocks . 17 6.2.1 Pure Block Layout . 17 6.2.2 Named Blocks . 17 6.2.3 Dummy Body Blocks . 18 6.2.4 Directives . 18 6.2.5 Case Statements (except in Python) . 18 6.3 Concurrency . 19 6.3.1 OpenMP and MPI . 19 6.4 Exception Handling in Java and C++ . 19 6.4.1 Use Judiciously . 19 6.4.2 Catch by Reference in C++ . 19 6.4.3 Constructor and Destructor Issues . 19 6.4.4 Re-throw the Same Exception in C++ . 19 6.4.5 Exception Handling in Java . 20 6.5 Prohibited Fortran Features . 20 7 Comments 20 7.1 Embedded Comments . 20 7.2 Comment Major Code . 21 7.3 Use Descriptive Comments . 21 7.4 Avoid In-line Comments . ..

Copy Link

Recommended publications

Java Programming Standards & Reference Guide
Java Programming Standards & Reference Guide Version 3.2 Office of Information & Technology Department of Veterans Affairs Java Programming Standards & Reference Guide, Version 3.2 REVISION HISTORY DATE VER. DESCRIPTION AUTHOR CONTRIBUTORS 10-26-15 3.2 Added Logging Sid Everhart JSC Standards , updated Vic Pezzolla checkstyle installation instructions and package name rules. 11-14-14 3.1 Added ground rules for Vic Pezzolla JSC enforcement 9-26-14 3.0 Document is continually Raymond JSC and several being edited for Steele OI&T noteworthy technical accuracy and / PD Subject Matter compliance to JSC Experts (SMEs) standards. 12-1-09 2.0 Document Updated Michael Huneycutt Sr 4-7-05 1.2 Document Updated Sachin Mai L Vo Sharma Lyn D Teague Rajesh Somannair Katherine Stark Niharika Goyal Ron Ruzbacki 3-4-05 1.0 Document Created Sachin Sharma i Java Programming Standards & Reference Guide, Version 3.2 ABSTRACT The VA Java Development Community has been establishing standards, capturing industry best practices, and applying the insight of experienced (and seasoned) VA developers to develop this “Java Programming Standards & Reference Guide”. The Java Standards Committee (JSC) team is encouraging the use of CheckStyle (in the Eclipse IDE environment) to quickly scan Java code, to locate Java programming standard errors, find inconsistencies, and generally help build program conformance. The benefits of writing quality Java code infused with consistent coding and documentation standards is critical to the efforts of the Department of Veterans Affairs (VA). This document stands for the quality, readability, consistency and maintainability of code development and it applies to all VA Java programmers (including contractors).
[Show full text]
Devsecops in Reguated Industries Capgemini Template.Indd
DEVSECOPS IN REGULATED INDUSTRIES ACCELERATING SOFTWARE RELIABILITY & COMPLIANCE TABLE OF CONTENTS 03... Executive Summary 04... Introduction 07... Impediments to DevSecOps Adoption 10... Playbook for DevSecOps Adoption 19... Conclusion EXECUTIVE SUMMARY DevOps practices enable rapid product engineering delivery and operations, particularly by agile teams using lean practices. There is an evolution from DevOps to DevSecOps, which is at the intersection of development, operations, and security. Security cannot be added after product development is complete and security testing cannot be done as a once-per-release cycle activity. Shifting security Left implies integration of security at all stages of the Software Development Life Cycle (SDLC). Adoption of DevSecOps practices enables faster, more reliable and more secure software. While DevSecOps emerged from Internet and software companies, it can benefit other industries, including regulated and high security environments. This whitepaper covers how incorporating DevSecOps in regulated Industries can accelerate software delivery, reducing the time from code change to production deployment or release while reducing security risks. This whitepaper defines a playbook for DevSecOps goals, addresses challenges, and discusses evolving workflows in DevSecOps, including cloud, agile, application modernization and digital transformation. Bi-directional requirement traceability, document generation and security tests should be part of the CI/CD pipeline. Regulated industries can securely move away
[Show full text]
Declaring Data Member Public C
Declaring Data Member Public C Rickard brooch stickily. Interceptive and hamulate Connie enure, but Norbert crossways extinguishes her patroness. Is Mario estimated or electrotonic when strangulating some moribundity deified deeply? Optimize for declaring data member public If dynamic allocation is necessary, prefer to keep ownership with the code that allocated it. This process of creating an object from a class is known as instantiation. Here is the quite surprising output of the program. Data attributes need not be declared; like local variables, they spring into existence when they are first assigned to. The term __________ means the ability to takemany forms. In many cases, this is not a problem, but it is a problem in some cases. Use rvalue references only in certain special cases listed below. By default, functions and data members of the class are public. How many data members should be in every class and why? Is it acceptable to omit default constructors in a class? For accessing the data, the declaration of a friend function should be done inside the body of a class starting with the keyword friend. The constructor is declared much like a normal member function but it will share the name of the class and it has no return value. Spirit would be impossible without it. The basic idea is really very simple. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments. Special member functions called constructors and destructors. This makes it impossible for the class to ensure that invariant properties of that variable are respected.
[Show full text]
Advanced Tcl E D
PART II I I . A d v a n c Advanced Tcl e d T c l Part II describes advanced programming techniques that support sophisticated applications. The Tcl interfaces remain simple, so you can quickly construct pow- erful applications. Chapter 10 describes eval, which lets you create Tcl programs on the fly. There are tricks with using eval correctly, and a few rules of thumb to make your life easier. Chapter 11 describes regular expressions. This is the most powerful string processing facility in Tcl. This chapter includes a cookbook of useful regular expressions. Chapter 12 describes the library and package facility used to organize your code into reusable modules. Chapter 13 describes introspection and debugging. Introspection provides information about the state of the Tcl interpreter. Chapter 14 describes namespaces that partition the global scope for vari- ables and procedures. Namespaces help you structure large Tcl applications. Chapter 15 describes the features that support Internationalization, includ- ing Unicode, other character set encodings, and message catalogs. Chapter 16 describes event-driven I/O programming. This lets you run pro- cess pipelines in the background. It is also very useful with network socket pro- gramming, which is the topic of Chapter 17. Chapter 18 describes TclHttpd, a Web server built entirely in Tcl. You can build applications on top of TclHttpd, or integrate the server into existing appli- cations to give them a web interface. TclHttpd also supports regular Web sites. Chapter 19 describes Safe-Tcl and using multiple Tcl interpreters. You can create multiple Tcl interpreters for your application. If an interpreter is safe, then you can grant it restricted functionality.
[Show full text]
Classes in C++
Classes in C++ Bryce Boe 2012/08/15 CS32, Summer 2012 B Overview • Finish Sor?ng recap • Thinking object oriented recap • Classes in C++ • Building a class in C++ (real ?me demo) Sor?ng recap • Bubble sort • Inser?on sort • Selec?on sort • Merge sort • Heapsort • Quicksort Thinking object oriented recap • Language as an inﬂuence of thought process • OO concepts – Separaon of interface and implementaon – Informaon hiding – Inheritance • Wri?ng reusable code Exci?ng Note for Today • The gcc compiler now requires C++ to build – Essen?ally means parts of the gcc compiler are wriVen in C++ • hp://gcc.gnu.org/git/? p=gcc.git;a=commit;h=2b15d2ba7eb3a25d]1 5a7300f4ee7a141ee8539 Structures • Structures provide a way to organize data • Structures in C++ are essen?ally classes, not true in C Classes • an object is a variable that has member func?ons (instance methods) • a class is a data type whose variables are objects • Class – Describe the kind of values the variables hold (state) – Describe the member func?ons (behavior) Terminology • The book uses member to mean a par?cular instance of a class • The book uses members to mean aributes of a class (variables and methods) • Funcon and method are somewhat used interchangeably • Similar: – member variable = instance variable – member method = instance method Classes • Provide encapsulaon – Combining a number of items, such as variables and func?ons, into a single package, such as an object of some class (or instance of the class) Scope Resolu?on Operator • ClassName::method_name • Used to iden?fy
[Show full text]
OHD C++ Coding Standards and Guidelines
National Weather Service/OHD Science Infusion and Software Engineering Process Group (SISEPG) – C++ Programming Standards and Guidelines NATIONAL WEATHER SERVICE OFFICE of HYDROLOGIC DEVELOPMENT Science Infusion Software Engineering Process Group (SISEPG) C++ Programming Standards and Guidelines Version 1.11 Version 1.11 11/17/2006 National Weather Service/OHD Science Infusion and Software Engineering Process Group (SISEPG) – C++ Programming Standards and Guidelines 1. Introduction..................................................................................................................1 2. Standards......................................................................................................................2 2.1 File Names .......................................................................................................2 2.2 File Organization .............................................................................................2 2.3 Include Files.....................................................................................................3 2.4 Comments ........................................................................................................3 2.5 Naming Schemes .............................................................................................4 2.6 Readability and Maintainability.......................................................................5 2.6.1 Indentation ...............................................................................................5 2.6.2 Braces.......................................................................................................5
[Show full text]
Theta Engineering Firmware Coding Conventions
Theta Engineering Firmware Coding Conventions Best Practices What constitutes “best practice” in software development is an ongoing topic of debate in industry and academia. Nevertheless, certain principles have emerged over the years as being sound and beneficial. In taking a conservative stance on this topic, we will avoid the most recent and contentious ideas and stick with the ones that have withstood the test of time. The principles we will use in the development of firmware are: o Object oriented design – Even though we are not programming in an “object oriented language” per se, the principles of object oriented design are still applicable. We will use a C module to correspond to an “object”, meaning a body of code that deals with a specific item or conceptually small zone of functionality, and encapsulates the code and data into that module. o Separation of interface and implementation – Each module will have a .c file that comprises the implementation and a .h file specifying the interface. Coding details and documentation pertaining to the implementation should be confined to the .c file, while items pertaining to the interface should be in the .h file. o Encapsulation – Each module should encapsulate all code and data pertaining to its zone of responsibility. Each module will be self contained and complete. Access to internal variables if necessary will be provided through published methods as described in the header file for the module. A module may use other appropriate modules in order to do its job, but may do so only through the published interface of those modules.
[Show full text]
Tsduck Coding Guidelines
TSDuck Coding Guidelines Version 3.2 April 2021 TSDuck coding guidelines License TSDuck is released under the terms of the license which is commonly referred to as "BSD 2-Clause License" or "Simplified BSD License" or "FreeBSD License". See http://opensource.org/licenses/BSD-2- Clause. Copyright (c) 2005-2021, Thierry Lelégard All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
[Show full text]
Towards a Structured Specification of Coding Conventions
1 Towards a Structured Specification of Coding Conventions Elder Rodrigues Jr. and Leonardo Montecchi Instituto de Computaçao˜ Universidade Estadual de Campinas Campinas, SP, Brazil [email protected], [email protected] Abstract—Coding conventions are a means to improve the check similarity between rules, ii) identify conflicting rules, reliability of software systems. They can be established for iii) understand if a tool is able to check a certain rule, iv) many reasons, ranging from improving the readability of code configure a tool to check a certain rule, etc. to avoiding the introduction of security flaws. However, coding conventions often come in the form of textual documents in Following the principles behind Model-Driven Engineering natural language, which makes them hard to manage and to (MDE) [20], all the artifacts in the software development pro- enforce. Following model-driven engineering principles, in this cess, thus including coding conventions, should be represented paper we propose an approach and language for specifying as structured models, to increase the degree of automation, coding conventions using structured models. We ran a feasibility improve integration, and reduce the possibility of human study, in which we applied our language for specifying 215 coding rules from two popular rulesets. The obtained results mistakes. However, to the best of our knowledge, there is little are promising and suggest that the proposed approach is feasible. work on this topic in the literature. However, they also highlight that many challenges still need to be In this paper we investigate the possibility of specifying cod- overcome. We conclude with an overview on the ongoing work for ing conventions through structured, machine-readable, models.
[Show full text]
Practical Programming in Tcl and Tk
Practical Programming in Tcl and Tk Brent Welch DRAFT, January 13, 1995 Updated for Tcl 7.4 and Tk 4.0 THIS IS NOT THE PUBLISHED TEXT THE INDEX IS INCOMPLETE SOME SECTIONS ARE MISSING THE MANUSCIRPT HAS NOT BEEN EDITED GET THE REAL BOOK: ISBN 0-13-182007-9 An enhanced version of this text has been published by Prentice Hall: ISBN 0-13-182007-9 Send comments via email to [email protected] with the word “book” in the subject. http://www.sunlabs.com/~bwelch/book/index.html The book is under copyright. Print for personal use only. This on-line DRAFT is available curtesty the kind folks at PH. Table of Contents 1. Tcl Fundamentals ............................................. 1 Getting Started ............................................................1 Tcl Commands .............................................................2 Hello World ..................................................................3 Variables ......................................................................3 Command Substitution ................................................4 Math Expressions ........................................................4 Backslash Substitution ................................................6 Double Quotes .............................................................7 Procedures ...................................................................7 A While Loop Example ..................................................8 Grouping And Command Substitution .......................10 More About Variable Substitution ..............................11
[Show full text]
About Classes 14.1 Instance and Static Members Tree Class
Ch 14: More About Classes 14.1 Instance and Static Members ! instance variable: a member variable in a class. Each object (instance) has its own copy. CS 2308 ! static variable: one variable shared among all Fall 2013 objects of a class Jill Seaman ! static member function: - can be used to access static member variable; ‣ normal functions can access static member variables, too - but it cannot access instance variables 1 - can be called before any objects are defined2 string name1 = “Steve Jobs”; string name1 = “Steve Jobs”; cout << “Name” << name1 << endl; cout << “Name” << name1 << endl; Tree class declaration Program demo of static variable // Tree class class Tree { private: Static member variable #include <iostream> static int objectCount; declared here using namespace std; public: #include "Tree.h" Tree(); int getObjectCount(); int main() { }; Tree oak; Tree elm; // Definition of the static member variable, written Tree pine; // outside the class. Static member variable int Tree::objectCount = 0; defined here (required) cout << “We have “ << pine.getObjectCount() // Member functions defined << “Trees in our program.\n”; Tree::Tree() { Static variable is incremented objectCount++; each time Tree is constructed. } } int Tree::getObjectCount() { return objectCount; What will be the output? } 3 4 string name1 = “Steve Jobs”; string name1 = “Steve Jobs”; cout << “Name” << name1 << endl; cout << “Name” << name1 << endl; Three Instances of the Tree Class, static member function But Only One objectCount Variable ! Declared with static
[Show full text]
More on Classes (Chapter 14.1, 14.3-14.5)
More on Classes (Chapter 14.1, 14.3-14.5) Dr. Yingwu Zhu 14.1 Instance and Static Members Instance and Static Members • instance variable: a member variable in a class. Each object has its own copy. • static variable: one variable shared among all objects of a class • static member function: can be used to access static member variable; can be called before any objects are defined 14-3 static member variable Contents of Tree.h 1 // Tree class 2 class Tree Static member declared here. 3 { 4 private: 5 static int objectCount; // Static member variable. 6 public: 7 // Constructor 8 Tree() 9 { objectCount++; } 10 11 // Accessor function for objectCount 12 int getObjectCount() const 13 { return objectCount; } 14 }; Static member defined here. 15 16 // Definition of the static member variable, written 17 // outside the class. 18 int Tree::objectCount = 0; 14-4 14-5 Three Instances of the Tree Class, But Only One objectCount Variable 14-6 static member function • Declared with static before return type: static int getObjectCount() const { return objectCount; } • Static member functions can only access static member data (Why ?) • Can be called independent of objects: int num = Tree::getObjectCount(); 14-7 Modified Version of Tree.h 1 // Tree class 2 class Tree 3 { 4 private: 5 static int objectCount; // Static member variable. 6 public: 7 // Constructor 8 Tree() 9 { objectCount++; } 10 11 // Accessor function for objectCount 12 static int getObjectCount() const 13 { return objectCount; } 14 }; 15 16 // Definition of the static member variable, written 17 // outside the class. 18 int Tree::objectCount = 0; Now we can call the function like this: cout << "There are " << Tree::getObjectCount() << " objects.\n"; 14-8 14.3 Memberwise Assignment Memberwise Assignment • Can use = to assign one object to another, or to initialize an object with an object’s data • Copies member to member.
[Show full text]