The following rules that are applicable to all C programs:
1. Each instruction in a C program is written as a separate statement. Therefore a complete C program would comprise of a series of statements.
2. The statements in a program must appear in the same order in which we wish them to be executed; unless of course the logic of the problem demands a deliberate ‘jump’ or transfer of control to a statement, which is out of sequence.
3.Blank spaces may be inserted between two words to improve the readability of the statement. However, no blank spaces are allowed within keyword.
4. All statements are entered in small case letters.
5. C has no specific rules for the position at which a statement is to be written.
6. Every C statement must end with a ;. Thus ; acts as a statement terminator.
7. Comment about the program should be enclosed within /* */.
For example, the first two statements in our program are comments.
8. Though comments are not necessary, it is a good practice to begin a program with a comment indicating the purpose of the program, its author and the date on which the program was written.
9. Any number of comments can be written at any place in the program. For example, a comment can be written before the statement, after the statement or within the statement as shown below:
/* formula */ si = p * n * r / 100 ; si = p * n * r / 100 ;
/* formula */ si = p * n * r / /* formula */ 100 ;
10. Sometimes it is not so obvious as to what a particular statement in a program accomplishes. At such times it is worthwhile mentioning the purpose of the statement (or a set of statements) using a comment.
For example:
/* formula for simple interest */
si = p * n * r / 100 ;
11. Often programmers seem to ignore writing of comments. But when a team is building big software well commented code is almost essential for other team members to understand it.
12. Although a lot of comments are probably not necessary in this program, it is usually the case that programmers tend to use too few comments rather than too many. An adequate number of comments can save hours of misery and suffering when you later try to figure out what the program does.
13. The normal language rules do not apply to text written within /* .. */. Thus we can type this text in small case, capital or a combination. This is because the comments are solely given for the understanding of the programmer or the fellow programmers and are completely ignored by the compiler.
14. Comments cannot be nested.
/* Cal of SI /* Author sam date 01/01/2002 */ */ is invalid.
15. A comment can be split over more than one line, as in,
/* This is a
multi
comment */
Such a comment is often called a multi-line comment.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
1. Each instruction in a C program is written as a separate statement. Therefore a complete C program would comprise of a series of statements.
2. The statements in a program must appear in the same order in which we wish them to be executed; unless of course the logic of the problem demands a deliberate ‘jump’ or transfer of control to a statement, which is out of sequence.
3.Blank spaces may be inserted between two words to improve the readability of the statement. However, no blank spaces are allowed within keyword.
4. All statements are entered in small case letters.
5. C has no specific rules for the position at which a statement is to be written.
6. Every C statement must end with a ;. Thus ; acts as a statement terminator.
7. Comment about the program should be enclosed within /* */.
For example, the first two statements in our program are comments.
8. Though comments are not necessary, it is a good practice to begin a program with a comment indicating the purpose of the program, its author and the date on which the program was written.
9. Any number of comments can be written at any place in the program. For example, a comment can be written before the statement, after the statement or within the statement as shown below:
/* formula */ si = p * n * r / 100 ; si = p * n * r / 100 ;
/* formula */ si = p * n * r / /* formula */ 100 ;
10. Sometimes it is not so obvious as to what a particular statement in a program accomplishes. At such times it is worthwhile mentioning the purpose of the statement (or a set of statements) using a comment.
For example:
/* formula for simple interest */
si = p * n * r / 100 ;
11. Often programmers seem to ignore writing of comments. But when a team is building big software well commented code is almost essential for other team members to understand it.
12. Although a lot of comments are probably not necessary in this program, it is usually the case that programmers tend to use too few comments rather than too many. An adequate number of comments can save hours of misery and suffering when you later try to figure out what the program does.
13. The normal language rules do not apply to text written within /* .. */. Thus we can type this text in small case, capital or a combination. This is because the comments are solely given for the understanding of the programmer or the fellow programmers and are completely ignored by the compiler.
14. Comments cannot be nested.
/* Cal of SI /* Author sam date 01/01/2002 */ */ is invalid.
15. A comment can be split over more than one line, as in,
/* This is a
multi
comment */
Such a comment is often called a multi-line comment.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
No comments:
Post a Comment