12 Coding Techniques
Dijkstra recognized that the goto statement was an inherently error-response programming construct. It made it difficult to localized state changes. This observation led to the development of so-called structured programming. Moreover, structured programming means programming without using go to statements, programming using only while loop and if statements as control constructs and designing using top-down approach. The adoption of structured programming was an important milestone in the development of software engineering because it was the first step away from an undisciplined approach to software development. The problems with structured programming are as follows:
• Only a limited number of control and data abstraction constructs are used. The program development process is a process of stepwise refinement of the specification.
• A limited number of constructs are used and the aim is to apply correctness-preserving transformation to the specification to create the program code.
• A computer program is said to be structured if it has a modular design and uses only the three types of logical structures, sequences, decisions and loops.
• Sequences: Statements are executed one after another.
• Decisions: One of two blocks of program code is executed based on a test for some condition.
• Loops (Iteration): One or more statements are executed repeatedly as long as a specified condition is true
Advantages of Structured programming
The goal of structured programming is to create correct programs that are easy to write, understand and change. They are easy to write programs by modular design. Moreover, modular design increases the programmer’s productivity by allowing them to look at the big picture first and focus on details later. In addition, several programmers can work on a single, large program, each working on a different module Studies show structured programs take less time to write than standard programs. Procedures written for one program can be reused in other programs requiring the same task. A procedure that can be used in many programs is said to be reusable.
It is easy to debug the programs written using structured programming languages since each procedure is specialized to perform just one task, a procedure can be checked individually. In addition, older unstructured programs consist of a sequence of instructions that are not grouped for specific tasks. The logic of such programs is cluttered with details and therefore difficult to follow. Moreover, such programs are easy to understand. Here, the relationship between the procedures shows the modular design of the program. Moreover, meaningful procedure names and clear documentation identify the task performed by each module and meaningful variable names help the programmer identify the purpose of each variable. Finally, the modular programming provides flexibility in modification since it is easy to change one module at a time. A correctly written structured program is self-documenting and hence it can be easily understood by another programmer.
PROGRAMMING STYLE
The following are the programming styles that are followed while writing programs.
• It is necessary to use internal documentation inside the programs. These notes provide guidelines for internal program documentation and style. Although they are intended for beginners in programming, style skills will carry over into professional life later.
• In fact, most professional programmers would consider these standards to be less than minimum requirements for commercial-quality software documentation. While geared mainly for a block structured language such as Pascal or C, most of the points discussed are applicable to any programming language.
• The essence of good programming style is communication. Good style in programming is roughly as difficult to learn as good style in English.
- In both cases, the document has no value if it does not convey its meaning to the reader. Any program that will be used must be maintained by somebody – and that somebody must be able to understand the code by reading it.
- Any program that needs debugging will be easier to debug if the creator carefully explains what’s going on.
GENERAL GUIDELINES FOR DOCUMENTATION
The most useful things to know about program documentation are “what” and “when”. In general, the programmer should include comments explaining what every subroutine does, what every variable does, and an explanation for every tricky expression or section of code. But, there is much to good style beyond comments where the programmer must comment the unnecessary styles before writing them. Whenever a programmer declares a variable, he/she should include a comment. Whenever they start to write a subroutine, they must first write a comment explaining it. That will help to make clear in the users mind what the programmers are about to do. If they find the explanation for a subroutine difficult to write, it is a sure sign that they have done a poor job of structuring the program.
The programmer must avoid obscure programming language constructs and reliance on language-specific precedence rules. It is often better to force precedence by use of parentheses since this leaves no doubt as to meaning. In general, if the programmer had to look up some rule or definition, their readers most likely will too. Whenever the programmer writes a difficult expression, or some other tricky business, if he/she found it difficult to write he/she should expect that it will be difficult to understand. So, it is necessary to add a comment. The most important rule of style is: be consistent! If someone adopts some method for variable naming or indenting, they must stick to it throughout their program.
INTERNAL DOCUMENTATION
Internal documentation comprises the code comprehension features provided as part of the source code itself. Internal documentation is provided through appropriate module header and comments embedded in the source code. Internal documentation is provided through the use of meaningful variable names, module and function headers, code indentation, code structuring, use of enumerated types and constant identifiers, use of user-defined data types, etc. Good software development organizations usually ensure good internal documentation by appropriately formulating their coding standards and coding guidelines.
CODING
Coding is undertaken once the design phase is complete and the design documents have been successfully reviewed. In this coding phase, every module identified and specified in the design document is independently coded. Good software development organizations require their programmers to adhere to some well-defined and standard style of coding is called coding standards.
CODING STANDARD AND GUIDELINES
Good software development organizations usually develop their own coding standards and guidelines depending on what best suits their needs and the steps of products they develop. Here, some general coding standards and guidelines which are commonly adopted by many software development organizations are provided rather than trying to provide an exhaustive list of representative coding standards and representative coding guidelines.
REPRESENTATIVE CODING STANDARDS
The use of global variables must be limited in a program. Contents of headers preceding codes for different modules. Naming convention for global variables, local variables and constant identifiers. Error return conventions and exception handling mechanisms.
REPRESENTATIVE CODING GUIDELINES
- Do not use a coding style that is too clever or too difficult to understand.
- Avoid obscure side effect and don’t use go-to statements.
- Do not use an identifier for multiple purposes.
- The code should be well-documented.
- The length of any function should not exceed 10 source lines unless it is necessary.
NAMES
The naming scheme is one of the most influential aids to understanding the logical flow of an application. A name should tell “what” rather than “how.” By avoiding names that expose the underlying implementation, which can change, the programmers can preserve a layer of abstraction that simplifies the complexity. For example, they can use GetNextStudent() instead of GetNextArrayElement(). A problem of naming is the difficulty in selecting a proper name which may indicate that the programmers need to further analyze or define the purpose of an item. It makes names long enough to be meaningful but short enough to avoid verbosity. Programmatically, a unique name serves only to differentiate one item from another. Expressive names function as an aid to a human reader; therefore, it makes sense to provide a name that a human reader can comprehend. However, be certain that the chosen names are in compliance with the applicable language’s rules and standards.
VARIABLES
The following rules must be followed to provide names in programming for variables.
Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable name where appropriate.
Use complementary pairs in variable names, such as min/max, begin/end, and open/close. Since most names are constructed by concatenating several words, use mixed-case formatting to simplify reading them. In addition, to help distinguish between variables and routines, use Pascal casing (CalculateInvoiceTotal) for routine names where the first letter of each word is capitalized. For variable names, use camel casing
(documentFormatType) where the first letter of each word except the first is capitalized. Boolean variable names should contain Is which implies Yes/No or True/False values,such as fileIsFound.
Avoid using terms such as Flag when naming status variables, which differ from Boolean variables in that they may have more than two possible values. Instead of documentFlag, use a more descriptive name such as documentFormatType.
Even for a short-lived variable that may appear in only a few lines of code, still use a meaningful name. Use single-letter variable names, such as i, or j, for short-loop indexes only.
Do not use literal numbers or literal strings, such as For i = 1 To 7. Instead, use named constants, such as For i = 1 To NUM_DAYS_IN_WEEK for ease of maintenance and understanding.
COMMENTS
Software documentation exists in two forms, external and internal. External documentation, such as specifications, help files, and design documents, is maintained outside of the source code. Internal documentation is comprised of comments that developers write within the source code at development time.
Despite the availability of external documentation, source code listings should be able to stand on their own because hard-copy documentation can be misplaced. External documentation should consist of specifications, design documents, change requests, bug history, and the coding standard used.
One challenge of internal software documentation is ensuring that the comments are maintained and updated in parallel with the source code. Although properly commenting source code serves no purpose at run time, it is invaluable to a developer who must maintain a particularly intricate or cumbersome piece of software.
CODING REVIEW
The code review for a module is carried out after the module is successfully compiled and all the syntax errors eliminated. Code reviews are extremely cost-effective strategies for reduction in coding error in order to produce high quality code. Normally two types of code reviews are carried out on the code of module-code walk through and code inspection.
Coding Walkthroughs
Code walk-through is a an informal code of analysis technique. In this technique after a module has been coded, it is successfully compiled and all syntax errors are eliminated. Some member of the development team are given the code a few days before the walkthrough meeting to read and understand the code. Each member selects some test cases and simulates execution of the code by hand. Objective of walk-through is to discover the algorithmic and logical error in the code. The team performing the code walk-through should not be either too big or too small. Ideally, it should consist of three to seven members. The discussion should focus on discovery of errors and not on how to fix the discovered errors. In order to foster cooperation and to avoid the feeling among the engineers that they are being evaluated in the code walk through meeting, managers should not attend the walk through meetings.
CODE INSPECTION
Software maintenance is the general process of changing a system after it has been diverted. The change may be simple changes to correct coding errors, more extensive changes to correct design errors or significant enhancement to correct specification error or accommodate new requirements. There are three types of software maintenance namely maintenance to repair software faults, maintenance to adapt the software to a different operating system and maintenance to add to or modify the system’s functionality. The maintenance activities include the checking of use of uninitialized variables, jumps into loops and non terminating loops, incompatible assignments, array indices out of bounds, improper storage allocation and de-allocation, mismatches between actual and formal parameters in procedure calls, use of incorrect logical operators or incorrect precedence among operators, improper modification of loops and comparison of equality of floating point values, etc.
SUMMARY
Coding is an important activity in software engineering process. Software size is optimised using coding. Selection of a programming language is important for good coding. Good coding practises, enhances the quality of software.
