Coding z At the end of the design

Coding z. At the end of the design phase we have: ymodule structure of the system ymodule specifications: xdata structures and algorithms for each module. z. Objective of coding phase: ytransform design into code yunit test the code. 1

Coding Standards z. Good software development organizations require their programmers to: yadhere some standard style of coding ycalled coding standards. 2

Coding Standards z. Many software development organizations: yformulate their own coding standards that suits them most, yrequire their engineers to follow these standards. 3

Coding Standards z. Advantage of adhering to a standard style of coding: yit gives a uniform appearance to the codes written by different engineers, yit enhances code understanding, yencourages good programming practices. 4

Coding Standards z. A coding standard ysets out standard ways of doing several things: xthe way variables are named, xcode is laid out, xmaximum number of source lines allowed per function, etc. 5

Coding guidelines z. Provide general suggestions regarding coding style to be followed. 6

Code inspection and code walk throughs z. After a module has been coded, ycode inspection and code walk through are carried out yensures that coding standards are followed yhelps detect as many errors as possible before testing. 7

Code inspection and code walk throughs z. Detect as many errors as possible during inspection and walkthrough: ydetected errors require less effort for correction xmuch higher effort needed if errors were to be detected during integration or system testing. 8

Coding Standards and Guidelines z. Good organizations usually develop their own coding standards and guidelines: ydepending on what best suits their organization. 9

Representative Coding Standards z. Rules for limiting the use of globals: ywhat types of data can be declared global and what can not. z. Naming conventions for yglobal variables, ylocal variables, and yconstant identifiers. 10

Representative Coding Standards z. Contents of headers for different modules: y. The headers of different modules should be standard for an organization. y. The exact format for header information is usually specified. 11

Representative Coding Standards z. Header data: y. Name of the module, ydate on which the module was created, yauthor's name, ymodification history, ysynopsis of the module, ydifferent functions supported, along with their input/output parameters, yglobal variables accessed/modified by the module. 12

z. Naming conventions for global variables, local variables, and constant identifiers: A possible naming convention can be that global variable names always start with a capital letter, local variable names are made of small letters, and constant names are always capital letters. 13

Representative Coding Standards z. Error return conventions and exception handling mechanisms. ythe way error and exception conditions are handled should be standard within an organization. y. For example, when different functions encounter error conditions xshould either return a 0 or 1 consistently. 14

Representative Coding Guidelines z. Do not use too clever and difficult to understand coding style. y. Code should be easy to understand. z. Many inexperienced engineers actually take pride: yin writing cryptic and incomprehensible code. 15

Representative Coding Guidelines z. Clever coding can obscure meaning of the code: yhampers understanding. ymakes later maintenance difficult. z. Avoid obscure side effects. 16

Representative Coding Guidelines z. Code should be well-documented. z. Rules of thumb: yon the average there must be at least one comment line xfor every three source lines. y. The length of any function should not exceed 10 source lines. 17

Representative Coding Guidelines z. Lengthy functions: yusually very difficult to understand yprobably do too many different things. 18

Representative Coding Guidelines z. Do not use goto statements. z. Use of goto statements: ymake a program unstructured ymake it very difficult to understand. 19

Code review z Code review for a model is carried out after the module is successfully compiled and the all the syntax errors have been eliminated. z Normally, two types of reviews are carried out on the code of a module. z These two types code review techniques are code inspection and code walk through. 20

Code Walk Through z. An informal code analysis technique. yundertaken after the coding of a module is complete. z. A few members of the development team select some test cases: ysimulate execution of the code by hand using these test cases. z. Discussion should focus on discovery of errors: yand not on how to fix the discovered errors. 21

z The main objectives of the walk through are to discover the algorithmic and logical errors in the code. z The members note down their findings to discuss these in a walk through meeting where the coder of the module is present. z The team performing code walk through should not be either too big or too small. y. Ideally, it should consist of between three to seven members. 22

Code Inspection z In contrast to code walk through, the aim of code inspection is to discover some common types of errors caused due to oversight and improper programming. z In addition to the commonly made errors, adherence to coding standards is also checked during code inspection. z Good software development companies collect statistics regarding different types of errors commonly committed by their engineers and identify the type of errors most frequently committed. z Such a list of commonly committed errors can be used during code inspection to look out for possible errors. 23

Commonly made errors z. Use of uninitialized variables. z. Nonterminating loops. z. Array indices out of bounds. z. Improper storage allocation and deallocation. z. Actual and formal parameter mismatch in procedure calls. z. Jumps into loops. 24

Code Inspection z. Use of incorrect logical operators yor incorrect precedence among operators. z. Improper modification of loop variables. z. Comparison of equality of floating point values, etc. z. Also during code inspection, yadherence to coding standards is checked. 25

Programming (Coding) Style & Conventions z Check for errors early and often. z Return from errors immediately. z Have you checked for compiler warnings? Warnings often point to real bugs. z If possible reduce object and file dependencies. z Eliminate needless import or include statements. z Check again for warnings or errors before committing source code. 26

27