| The Personal Software Process: an Independent Study | ||
|---|---|---|
| Prev | Chapter 2. Lesson 2: Planning and Measurement | Next |
Produce a standard specifying how you will count LOC. Objectives: to define the LOC counting standards that are appropriate for the programming language you use, to provide a basis for developing a coding standard, and to prepare for developing a program to count LOC.
Table 2-3. LOC counting standard for this independent study
| Definition Name: | C++ coding standard | Language: | C++ |
| Author: | Victor B. Putz | Date: | 991222 |
| Count Type | Type | Comments |
| Physical/Logical | Logical |
| Statement Type | Included? | Comments |
| Executable | Yes | |
| Nonexecutable: | ||
| Declarations | yes | Variable declarations, etc. |
| Compiler directives | no | Particularly for the PSP problems, this will be simple. As I add "include guards" on every file #included in a C++ file, adding compiler directives will swell LOC counts unacceptably. |
| Comments | no | Not appropriate-- they do not add complexity. No comments (standalone, banners, inline) should be counted as a LOC. |
| Clarifications | Included | Examples/Cases |
| Empty statements | no | Empty statements do nothing, so should not be counted as adding complexity, imho. |
| begin/end pairs ({}) | no | Brackets signify compound statements, but I'm interested in the statements themselves rather than their grouping. Since my code standard uses brackets for all statements in for-loops, if-branches, etc., including brackets would significantly inflate LOC. |
| End symbols (;) | no | These signify the ends of logical statements, but the coding style will have one logical line per physical line. For-loops have multiple semicolons in the header, but since I view the for-loop as a single construct (and won't do additional processing in the header), this should be fine. |
| Then, else, if | yes | "else if" will be counted as one statement |
| Keywords | yes | lone keywords (case, do, else, enum, for, etc...) |
Table 2-4. LOC counting standard for this independent study
| Definition Name: | Eiffel coding standard | Language: | Eiffel |
| Author: | Victor B. Putz | Date: | 991222 |
| Count Type | Type | Comments |
| Physical/Logical | Logical |
| Statement Type | Included? | Comments |
| Executable | Yes | |
| Nonexecutable: | ||
| Declarations | yes | Variable declarations, etc. |
| Compiler directives | n/a | (no compiler directives for SmallEiffel) |
| Comments | no | Not appropriate-- they do not add complexity. No comments (standalone, banners, inline) should be counted as a LOC. |
| Clarifications | Included | Examples/Cases |
| Empty statements | no | Same as C++; I will not use semicolons unless necessary to denote empty statements. |
| begin/end pairs | no | Same logic as with C++. Begin/end is used a great deal in Eiffel (feature sections, etc.) but I would rather not count these. |
| End symbols (;) | no | As mentioned-- I won't delimit statements with semicolons, so shouldn't count them. |
| Keywords | yes | lone keywords (inspect, from, until, loop, etc.) |