World Library  
Flag as Inappropriate
Email this Article

Coding conventions

Article Id: WHEBN0007969681
Reproduction Date:

Title: Coding conventions  
Author: World Heritage Encyclopedia
Language: English
Subject: Naming convention (programming), Source code, Software quality
Collection: Source Code
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Coding conventions

Coding conventions are a set of guidelines for a specific indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers. As a result, not following some or all of the rules has no impact on the executable programs created from the source code.

Contents

  • Software maintenance 1
    • Software engineering 1.1
      • Project specifications 1.1.1
    • Quality 1.2
      • Coding standards 1.2.1
      • Driving down complexity 1.2.2
    • Refactoring 1.3
  • Task automation 2
  • Language factors 3
  • Common conventions 4
  • See also 5
  • References 6
  • External links 7
    • Coding conventions for languages 7.1
    • Coding conventions for projects 7.2

Software maintenance

Reducing the cost of software maintenance is the most often cited reason for following coding conventions. In their introduction to code conventions for the Java programming language, Sun Microsystems provides the following rationale:[1]

Code conventions are important to programmers for a number of reasons:
  • 40%–80% of the lifetime cost of a piece of software goes to maintenance. [2]
  • Hardly any software is maintained for its whole life by the original author.
  • Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
  • If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Software engineering

Software engineering is the process by which the project is specified and designed. It is absolutely fundamental to the success of projects, particularly if they are large projects. The software engineering process is what runs the coding process to successful completion. Good software engineering can make the difference between a successful project - both in financial and engineering terms - and a project that is, at worst, dead on delivery. Good software engineering will minimise downstream costs and maximise the marketing success of the project.

Project specifications

The following documents need to be produced:

  1. The project brief. This is what kicks off the project. It is basically a brief description of the project and does not form a part of the formal document chain.
  2. The requirements specification. This specifies what the project is to do. It is the fundamental part of the document chain. All other documents relate to it.
  3. The project design. This is the formal design document of the project. It specifies the modules and the components, what their interfaces are and how they are connected. The software engineer, in carrying out this task, is looking at all the various ways to design the project and is choosing the best ways. He/She is taking into consideration all aspects including technical, quality, managerial, logistical and commercial. This includes time and cost of development, maintenance, support and usage of - both upfront and downstream. Part of this job is the architectural design but it goes a lot farther than that.
  4. The test specification. This specifies all the tests that are to be performed and what results are to be checked for. Often tests are run within automated test harnesses and the tests specified either within code files or script files.
  5. The test results.

The project specifications all the way down to the test results form what is called a document chain. Each document has a 1:1 relationship to the previous document. And ultimately the test specification has a 1:1 relationship to the requirements specification. The document chain is bidirectional - specifications going down, results coming back up.

These methods are called formal methods.

Quality

Software peer review frequently involves reading source code. This type of peer review is primarily a defect detection activity. By definition, only the original author of a piece of code has read the source file before the code is submitted for review. Code that is written using consistent guidelines is easier for other reviewers to understand and assimilate, improving the efficacy of the defect detection process.

Even for the original author, consistently coded software eases maintainability. There is no guarantee that an individual will remember the precise rationale for why a particular piece of code was written in a certain way long after the code was originally written. Coding conventions can help. Consistent use of whitespace improves readability and reduces the time it takes to understand the software.

Coding standards

Where coding conventions have been specifically designed to produce high-quality code, and have then been formally adopted, they then become coding standards. Specific styles, irrespective of whether they are commonly adopted, do not automatically produce good quality code. It is only if they are designed to produce good quality code that they actually result in good quality code being produced, i.e., they must be very logical in every aspect of their design - every aspect justified and resulting in quality code being produced.

Good procedures, good methodology and good coding standards can be used to drive a project such that the quality is maximized and the overall development time and development and maintenance cost is minimized.

Driving down complexity

The management of complexity is very important. There is a very basic principle - during the project development ask the question - "has this project been implemented with the least amount of code necessary ?". If it hasn't then unnecessary work has been undertaken and unnecessary cost - both upfront and downstream - has been incurred. This is the "Keep it Simple" rule - simple but effective.

Complexity is managed both at the design stage - how the project is architectured - and at the development stage - what coding is used. If the coding is kept basic and simple then the complexity will be minimised. Very often this is keeping the coding as 'physical' as possible - coding in a manner that is very direct and not highly abstract. This produces optimal code that is easy to read and follow.

The more complex the code is the more likely it is to be buggy, the more difficult the bugs are to find and the more likely there are to be hidden bugs. Safe coding is very important.

Refactoring

Refactoring refers to a software maintenance activity where source code is modified to improve readability or improve its structure. Software is often refactored to bring it into conformance with a team's stated coding standards after its initial release. Any change that does not alter the behavior of the software can be considered refactoring. Common refactoring activities are changing variable names, renaming methods, moving methods or whole classes and breaking large methods (or functions) into smaller ones.

Agile software development methodologies plan for regular (or even continuous) refactoring making it an integral part of the team software development process.[3]

Task automation

Coding conventions allow to have simple scripts or programs whose job is to process source code for some purpose other than compiling it into an executable. It is common practice to count the software size (Source lines of code) to track current project progress or establish a baseline for future project estimates.

Consistent coding standards can, in turn, make the measurements more consistent. Special tags within source code comments are often used to process documentation, two notable examples are javadoc and doxygen. The tools specify the use of a set of tags, but their use within a project is determined by convention.

Coding conventions simplify writing new software whose job is to process existing software. Use of static code analysis has grown consistently since the 1950s. Some of the growth of this class of development tools stems from increased maturity and sophistication of the practitioners themselves (and the modern focus on safety and security), but also from the nature of the languages themselves.

Language factors

All software practitioners must grapple with the problems of organizing and managing very many detailed instructions, each of which will eventually be processed in order to perform the task for which it was written. For all but the smallest software projects, source code (instructions) are partitioned into separate files and frequently among many directories. It was natural for programmers to collect closely related functions (behaviors) in the same file and to collect related files into directories. As software development evolved from purely procedural programming (such as found in FORTRAN) towards more object-oriented constructs (such as found in C++), it became the practice to write the code for a single (public) class in a single file (the 'one class per file' convention).[4][5] Java has gone one step further - the Java compiler returns an error if it finds more than one public class per file.

A convention in one language may be a requirement in another. Language conventions also affect individual source files. Each compiler (or interpreter) used to process source code is unique. The rules a compiler applies to the source creates implicit standards. For example, Python code is much more consistently indented than, say Perl, because whitespace (indentation) is actually significant to the interpreter. Python does not use the brace syntax Perl uses to delimit functions. Changes in indentation serve as the delimiters.[6][7] Tcl, which uses a brace syntax similar to Perl or C/C++ to delimit functions, does not allow the following, which seems fairly reasonable to a C programmer:

 set i 0
 while {$i < 10} 
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

The reason is that in Tcl, curly braces are not used only to delimit functions as in C or Java. More generally, curly braces are used to group words together into a single argument.[8][9] In Tcl, the word while takes two arguments, a condition and an action. In the example above, while is missing its second argument, its action (because the Tcl also uses the newline character to delimit the end of a command).

Common conventions

There are a large number of coding conventions; see Coding Style for numerous examples and discussion. Common coding conventions may cover the following areas:

See also

References

  1. ^ "Code Conventions for the Java Programming Language : Why Have Code Conventions". Sun Microsystems, Inc. 1999-04-20. 
  2. ^ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
  3. ^ Jeffries, Ron (2001-11-08). "What is Extreme Programming? : Design Improvement". XP Magazine. 
  4. ^ Hoff, Todd (2007-01-09). "C++ Coding Standard : Naming Class Files". 
  5. ^ FIFE coding standards
  6. ^ van Rossum, Guido (2006-09-19). Fred L. Drake, Jr, ed. "Python Tutorial : First Steps Towards Programming". Python Software Foundation. 
  7. ^ Raymond, Eric (2000-05-01). "Why Python?". Linux Journal. 
  8. ^ Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState. 
  9. ^ Staplin, George Peter (2006-07-16). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'. 

External links

Coding conventions for languages

  • ActionScript: Flex SDK coding conventions and best practices
  • Ada: Ada 95 Quality and Style Guide: Guidelines for Professional Programmers
  • Ada: Guide for the use of the Ada programming language in high integrity systems (ISO/IEC TR 15942:2000)
  • Ada: NASA Flight Software Branch — Ada Coding Standard
  • Ada: European Space Agency's Ada Coding Standard (BSSC(98)3)
  • C: Ganssle Group's Firmware Development Standard
  • C: Netrino Embedded C Coding Standard
  • C: Micrium C Coding Standard (dead link)
  • C++: Quantum Leaps C/C++ Coding Standard
  • C++: C++ Programming/Programming Languages/C++/Code/Style Conventions
  • C++: GeoSoft's C++ Programming Style Guidelines
  • C++: Google's C++ Style Guide
  • C++: High Integrity C++
  • C#: C# Coding Conventions (C# Programming Guide)
  • C#: Design Guidelines for Developing Class Libraries
  • C#: Brad Abrams
  • C#: Philips Healthcare
  • D: The D Style
  • Dart: The Dart Style Guide
  • Erlang: Erlang Programming Rules and Conventions
  • Flex: Code conventions for the Flex SDK
  • Java: Ambysoft's Coding Standards for Java
  • Java: Code Conventions for the Java Programming Language
  • Java: GeoSoft's Java Programming Style Guidelines
  • Java: Java Coding Standards at DMOZ
  • Java: SoftwareMonkey's Coding Standards for Java and other C-like languages
  • JavaScript: Code Conventions for the JavaScript Programming Language
  • Lisp: Riastradh's Lisp Style Rules
  • MATLAB: Neurobat Coding Conventions for MATLAB
  • Mono: Programming style for Mono
  • Object Pascal: Object Pascal Style Guide
  • Perl: Perl Style Guide
  • PHP::PEAR: PHP::PEAR Coding Standards
  • PHP::FIG: PHP Framework Interop Group
  • Python: Style Guide for Python Code
  • Ruby: The Unofficial Ruby Usage Guide
  • Ruby: GitHub Ruby style guide

Coding conventions for projects

  • Apache Developers' C Language Style Guide
  • Drupal PHP Coding Standards
  • Zend Framework Coding Standards
  • GNU Coding Standards
  • Style guides for Google-originated open-source projects
  • Linux Kernel Coding Style (or Documentation/CodingStyle in the Linux Kernel source tree)
  • ModuLiq Zero Indent Coding Style
  • Mozilla Coding Style Guide
  • Road Intranet's C++ Guidelines
  • The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)
  • OpenBSD Kernel source file style guide (KNF)
  • "GNAT Coding Style: A Guide for GNAT Developers". GCC online documentation. Free Software Foundation. Retrieved 2009-01-19.  (PDF)
  • ZeroMQ C Language Style for Scalability (CLASS)
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.