Published on

This presentation consists of coding rules and guidelines related to software development process.

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. The Coding Guidelines by Vishal Singh (
  2. 2. Coding• Coding is undertaken once the design phase is complete and the design documents have been successfully reviewed. In the coding phase, every module identified and specified in the design document is independently coded and unit tested.• The input to the coding phase is the design document.• During the coding phase, different modules identified in the design document are coded according to the respective module specifications.
  3. 3. Most software development organizations formulate their own coding standards that suit them most and require their engineers to follow these standards rigorously due to the following reasons:• A coding standard gives a uniform appearance to the codes written by different engineers.• It provides sound understanding of the code.• It encourages good programming practice.
  4. 4. 2. Programming practice:• The primary goal of the coding phase is to translate the given design into source code in a given programming language, so that the code is simple easy to test and easy to understand and modify.• So now we will discuss some concepts related to coding in a language independent manner.
  5. 5. • 2.1 Top-Down and Bottom –up: All design contains hierarchies as creating a hierarchy is a natural way to manage complexity. Most design methodologies for software also produce hierarchies. The question at coding time is; given the hierarchy of modules produced by design, in what order the modules be built—starting form the top or starting from the bottom level?.• In a Top down implementation, the implementation starts from the top of the hierarchy and proceeds to the lower levels. In a Bottom-up implementation the process is the reverse.
  6. 6. • 2.2 Structured programming: Structured programming is often regarded as “goto- less” programming. Although extensive use of gotos is certainly not desirable, structured program can be written with the use of gotos. Here we provide a brief discussion on what the structured programming is.• A program has a static structure as well as dynamic structure. The static structure is the structure of the text of the program, which is usually just a linear organization of statements of the program. The dynamic structure of the program is the sequence of statements executed during the execution of the program.• The goal of structured programming is to ensure that the static structure and the dynamic structures are the same.
  7. 7. 2.3 Information hiding:• Information hiding can reduce the coupling between modules and make the system more maintainable.• Information hiding is also an effective tool for managing the complexity of developing software.• Another form of information hiding is to let a module see only those data items needed by it.
  8. 8. • 2.4 Programming style: The programming style consists of some standard and guidelines which we will discuss in the next section of this presentation.
  9. 9. 2.5 Internal documentation:• Internal documentation of the program is done by the use of comments. All languages provide a means for writing comments in program. Comments are textual statements that are meant for the program reader and are not executed.
  10. 10. Comments for a module are often called prologue for the module. It is best to standardize the structure of the prologue of the module. It is desirable if the prologue contains the following information:• Module functionality or what the module is doing.• Parameters and their purpose.• Assumptions about the inputs, if any.• Global variables accessed or modified in the module.
  11. 11. 3. Coding Standards• General coding standards pertain to how the developer writes code, so here we will discuss some important standard regardless of the programming language being used. 3.1 Indentation• Proper and consistent indentation is important in producing easy to read and maintainable programs. Indentation should be used to:• Emphasize the body of a control statement such as a loop or a select statement• Emphasize the body of a conditional statement• Emphasize a new scope block
  12. 12. 3.2 Inline Comments• Inline comments explaining the functioning of the subroutine or key aspects of the algorithm shall be frequently used. 3.3 Structured Programming• Structured (or modular) programming techniques shall be used. GO TO statements shall not be used as they lead to “spaghetti” code, which is hard to read and maintain, except as outlined in the FORTRAN Standards and Guidelines.
  13. 13. • 3.4 Classes, Subroutines, Functions, and Methods• Keep subroutines, functions, and methods reasonably sized. This depends upon the language being used. A good rule of thumb for module length is to constrain each module to one function or action (i.e. each module should only do one “thing”).• The names of the classes, subroutines, functions, and methods shall have verbs in them. That is the names shall specify an action, e.g. “get_name”, “compute_temperature”.
  14. 14. 3.5 Source Files• The name of the source file or script shall represent its function. All of the routines in a file shall have a common purpose. 3.6 Variable Names• Variable shall have mnemonic or meaningful names that convey to a casual observer, the intent of its use. Variables shall be initialized prior to its first use.
  15. 15. 3.7 Use of BracesBad:if (j == 0) printf (“j is zero.n”);Better:if (j == 0){ printf (“j is zero.n”);}
  16. 16. 3.8 Compiler Warnings• Compilers often issue two types of messages: warnings and errors. Compiler warnings normally do not stop the compilation process. However, compiler errors do stop the compilation process, forcing the developer to fix the problem and recompile.• Compiler and linker warnings shall be treated as errors and fixed. Even though the program will continue to compile in the presence of warnings, they often indicate problems which may affect the behavior, reliability and portability of the code.
  17. 17. 4. Coding Guidelines• General coding guidelines provide the programmer with a set of best practices which can be used to make programs easier to read and maintain.• Most of the examples use the C language syntax but the guidelines can be applied to all languages.
  18. 18. • 4.1 Line Length• It is considered good practice to keep the lengths of source code lines at or below 80 characters. Lines longer than this may not be displayed properly on some terminals and tools. Some printers will truncate lines longer than 80 columns.
  19. 19. 4.2 SpacingThe proper use of spaces within a line of code can enhance readability.Example:Bad:cost=price+(price*sales_tax);fprintf(stdout ,“The total cost is %5.2fn”,cost);Better:cost = price + ( price * sales_tax );fprintf (stdout, “The total cost is %5.2fn”, cost) ;
  20. 20. 4.3 Wrapping LinesWhen an expression will not fit on a single line, break it according to these following principles:• Break after a commaExample:Bad:longName1 = longName2 * (longName3 + LongName4 –longName5) + 4 * longName6 ;Better:longName1 = longName2 * (longName3 + LongName4 – LongName5)+ 4 * longName6 ;
  21. 21. 4.4 Variable DeclarationsVariable declarations that span multiple lines should always be preceded by a type.Example:Acceptable:int price , score ;Acceptable:int price ;int score ;Not Acceptable:int price ,score ;
  22. 22. 4.5 Program StatementsProgram statements should be limited to one per line. Also, nested statements should be avoided when possible.Example:Bad:number_of_names = names.length ; b = new JButton [ number_of_names ] ;Better:number_of_names = names.length ;b = new JButton [ number_of_names ] ;
  23. 23. 4.6 Use of ParenthesesIt is better to use parentheses liberally. Even in cases where operator precedence unambiguously dictates the order of evaluation of an expression, often it is beneficial from a readability point of view to include parentheses anyway.Example:Acceptable:total = 3 – 4 * 3 ;Better:total = 3 – ( 4 * 3 ) ;Even better:total = ( -4 * 3 ) + 3 ;
  24. 24. 4.7 Inline Comments• Inline comments promote program readability. 4.8 Meaningful Error Messages• Error handling is an important aspect of computer programming. This not only includes adding the necessary logic to test for and handle errors but also involves making error messages meaningful.
  25. 25. 4.10 Reasonably Sized Functions and Methods Software modules and methods should not contain an excessively large number of lines of code. They should be written to perform one specific task. If they become too long, then chances are the task being performed can be broken down into subtasks which can be handled by new routines or methods. A reasonable number of lines of code for routine or a method is 200.
  26. 26. 5. Software documentation: Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it, or may mean different things to people in different roles.
  27. 27. Involvement of people in software life Documentation is an important part of software engineering. Types of documentation include:• Requirements - Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what shall be or has been implemented.• Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components.• Technical - Documentation of code, algorithms, interfaces, and APIs.• End User - Manuals for the end-user, system administrators and support staff.• Marketing - How to market the product and analysis of the market demand.
  28. 28. 5.1 Requirements documentationRequirements documentation is the description of what a particular software does or shall do.5.2 Architecture/Design documentationA good architecture document is short on details but thick on explanation.A very important part of the design document is the Database Design Document (DDD). It contains Conceptual, Logical, and Physical Design Elements.
  29. 29. 5.3 Technical documentation This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation.5.4 User documentation Unlike code documents, user documents are usually far more diverse with respect to the source code of the program, and instead simply describe how it is used.
  30. 30. There are three broad ways in which user documentation can be organized.• Tutorial: A tutorial approach is considered the most useful for a new user, in which they are guided through each step of accomplishing particular tasks.• Thematic: A thematic approach, where chapters or sections concentrate on one particular area of interest, is of more general use to an intermediate user. Some authors prefer to convey their ideas through a knowledge based article to facilitating the user needs. This approach is usually practiced by a dynamic industry, such as this Information technology, where the user population is largely correlated with the troubleshooting demands.• List or Reference: The final type of organizing principle is one in which commands or tasks are simply listed alphabetically or logically grouped, often via cross-referenced indexes. This latter approach is of greater use to advanced users who know exactly what sort of information they are looking for.
  31. 31. 5.5 Marketing documentation For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has three purposes:-• To excite the potential user about the product and instill in them a desire for becoming more involved with it.• To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.• To explain the position of this product with respect to other alternatives.
  32. 32. 6. Code verification techniques Verification of the output of the coding phase is primarily intended for detecting errors introduced during this phase.6.1 Code reading Code reading involves careful reading of the code by the programmer to detect any discrepancies between the design specifications and the actual implementation.6.2 Static analysis Analysis of programs by methodically analyzing the program text is called static analysis. Static analysis is usually performed mechanically by the aid of software tools.
  33. 33. 6.3 Code inspections or reviews• The review process was started with the purpose of detecting defects in the code.• Code reviews are designed to detect defects that originate during the coding process, although they can also detect defects in detailed design.
  34. 34. The following are some of the items that can be included in a checklist for code reviews:• Are the pointers set to NULL, where needed?• Are all the array indexes within bound?• Are indexes properly initialized?• Do data definitions exploit the typing capabilities of the language?• Do all pointers point to some object?• Will a loop always terminate?• Is the loop termination condition correct?• Is the number of loop execution “off by one”?• Where applicable, are the divisors tested for zero?• Are imported data tested for validity?• Do actual and formal parameters match?• Are all variables used?• Are the label unreferenced?
  35. 35. 6.5 Unit testing• Unit testing is a dynamic method for verification where the program is actually compiled and executed. It is one of the most widely used methods and the coding phase is sometime called the “coding and unit testing phase”. As in other forms of testing unit testing involves executing the code with some test cases and then evaluating the results.