Intermediate C Programming

158 Intermediate C Programming

i f ( onechar == ’C ’)5

charcount [2] ++;6

i f ( onechar == ’D ’)7

charcount [2] ++;8

i f ( onechar == ’E ’)9

charcount [3] ++;10

Fifty-two conditions are needed. The problem should be obvious: It is easy to make mistakes.

If fact, there are mistakes in the code above. Can you detect them easily? There is a general

principle in writing good programs: Do not copy-paste code. Write DRY code. DRY stands

for “Don’t Repeat Yourself”. The opposite of DRY code is WET code, which stands for

“We Enjoy Typing”.

There are many reasons to follow the DRY principle. If you copy-paste code, then you

increase the chances of mistakes. This is especially true when the code is modiﬁed after it is

written. Once we have two (or more) pieces of WET code, testing, debugging and improving

the code becomes more diﬃcult. We need to remember to change all places that the code is

repeated. If we forget to change some places, then the program will surprise you: In some

situations, the program is correct, but in others it fails.

There are many simple and clear solutions that avoid WET code. For example, if the

two (or more) pieces of code are identical, then create a function and call it twice. If they

are mostly similar but with a few diﬀerences, then the function’s arguments can handle the

diﬀerences. Spending some time ﬁxing WET code usually helps tremendously in developing

good test cases, since the programmer must think about and ultimately understand the

code. That also helps with debugging, since you will be more familiar with how the program

should behave as you step through it line by line.

Line 49 is the reverse way of using the ASCII values. If the index is 0, it corresponds to

’A’ so the value of ’A’ is added. The output of this program will look something like:

A: 39

B: 1

C: 41

D: 16

E: 69

F: 38

11.3 Counting the Occurrences of a Word

This program takes three arguments:

1. argv[1]: The name of the input ﬁle.

2. argv[2]: The name of the output ﬁle.

3. argv[3]: A word to be searched for.

This program detects and counts the occurrences of the word in an input ﬁle. If a line

in the input ﬁle includes the word, the program writes that line to the output ﬁle. After

checking all lines in the input ﬁle, the program writes the total count to the output ﬁle. We

must ﬁrst think about how words are counted. If the search word is “eye” and a line in the

input ﬁle contains “eyeye”, do you count 1 or 2? Both deﬁnitions are acceptable in diﬀerent

circumstances and we need to decide which deﬁnition to use. We will explain how to handle

the diﬀerences. For simplicity, each line in the input ﬁle contains at most 80 characters (and

Programming Problems Using File 159

thus needs memory for 81 characters). The program does not count a word that spans two

or more lines. The program uses strstr to search a word within a line.

// countst r . c1

#in clude < stdio .h >2

#in clude < stdlib .h >3

#in clude < string .h >4

#d ef in e LINE _ LENGTH 815

int main ( i n t argc , char * argv [])6

i f ( argc < 4) // input word output8

return EXIT _FAILUR E ;10

}11

// open the input file12

FILE * infptr ;13

infptr = fopen ( argv [1] , "r ");14

i f ( infptr == NULL )15

{16

return EXIT _FAILUR E ;17

}18

// open the output file19

FILE * outfptr ;20

outfptr = fopen ( argv [2] , "w ");21

i f ( outfptr == NULL )22

{23

fclose ( infptr ) ;24

return EXIT _FAILUR E ;25

}26

int count = 0;27

char oneline [ LINE_L ENGTH ];28

while ( fgets ( oneline , LINE_LENGTH , infptr ) != NULL )29

{30

i f ( strstr ( oneline , argv [3]) != NULL )31

{32

fprintf ( outfptr , "% s" , oneline );33

}34

char * chptr = oneline ;35

while ( chptr != NULL )36

{37

chptr = strstr ( chptr , argv [3]) ;38

i f ( chptr != NULL )39

{40

count ++;41

// if " eyeye " counts as two " eye "42

chptr ++;43

// if " eyeye " counts as one " eye "44

// chptr += strlen ( argv [3]) ;45

}46

}47

}48

160 Intermediate C Programming

fprintf ( outfptr , "% d\n ", count );49

// close the input file50

fclose ( infptr ) ;51

// close outupt file52

fclose ( outfptr );53

return EXIT _SUCCES S ;54

}55

Lines 41 and 45 implement the two deﬁnitions. Line 41 increments the address by only

one and searches again. Line 45 increments the address by length of the string. So “eyeye”

contains only one “eye”, because after ﬁnding the ﬁrst “eye”, the program continues its

search from “ye”.

11.4 How to Comment Code

Almost every programming class requires that students comment their code. Addition-

ally, almost every programming book tells readers to comment their code. However, very

few classes or books say how to comment code. Writing comments is like writing an article

and it is diﬃcult to grade comments. Comments are about communicating with the readers

of the code: Style and clarity are important. If comments do not explain code, then they are

not useful. It is not yet possible to check comments’ usefulness by using computer programs.

Grading comments by human eyes (usually by teaching assistants) is labor-intense. As a

result, some professors do not consider comments in grading and most students do not take

comments seriously. Sometimes students even write comments like “because the professors

tell us so.” Some students ask me, “Do I need to write comments for you?” My answer is,

“You need to write comments for yourself.” If your program is longer than, say, 20 lines,

you need to write comments before writing code.

This book frequently lists the steps before writing a program. These steps should be

written in the comments of the code. Remember that programs are written to solve prob-

lems. The programs implement solutions. The solution must be known before the ﬁrst line

of code is typed. Writing a program without a solution ﬁrst is like laying bricks for a house

before knowing how many rooms the house will have. Almost everyone agrees that a house

needs to be designed before it is built. Write code after you know the solution. It is good

practice to think about the solution, write down the steps, explain your thinking process in

comments.

In addition to explaining the steps, comments are needed to explain speciﬁcs of how

functions work: what is required of the arguments, and what the return result means.

Manual pages are good examples of this. Consider the manual page for fgets:

char *fgets(char *s, int size, FILE *stream);

fgets() reads in at most one less than size characters from

stream and stores them into the buffer pointed to by s. Reading

stops after an EOF or a newline. If a newline is read, it is stored

into the buffer. A terminating null byte (’\0’) is stored after the

last character in the buffer.

fgets() return s on success, and NULL on error or when end of

file occurs while no characters have been read.

Programming Problems Using File 161

This explains the arguments, the behavior of the function, and the return value. Notice

how clear and dense the text is. No word is wasted.

A common mistake is to repeat information that is obvious from the syntax. The fol-

lowing comment is unnecessary:

/* This function has two arguments . Both are integers .1

The funct i on returns an integer . */2

int func ( i n t a , in t b );3

Compare with the informative comment:

/* The functi o n returns1

1 if a > b2

0 if a == b3

-1 if a < b4

*/5

int func ( i n t a , in t b );6

Comments should provide some information that is unavailable from the syntax. Com-

ments are important when explaining complex concepts. The example below shows a call

stack:

---------------------------------------

---------------------------------------

| | z | 103 | 5 |

| f2 | y | 102 | 8 |

| | x | 101 | -7 |

---------------------------------------

We can also use comments to show the ﬂow of a function:

open input file -> count the number of lines -|

----------------------------------------------|

---> allocate memory -> return to the beginning of the file

The following is also good for those who do not like drawing:

1. open input file

2. count the number of lines

3. allocate memory

4. return to the beginning of the file

It should be apparent that comments can express important concepts. It takes practice

to write comments well. It is often helpful to read others’ code to see what comments are

162 Intermediate C Programming

useful, and what are merely distractions. This is important for your own code. If you read

a program written six months ago, can you understand it easily? If the meaning is not

apparent, then the commenting can be improved.

With practice, comments become a good way to further understand your code by testing

your ability to explain it. This, in turn, helps catch subtle problems, and also helps you

generate good test cases. By guiding the eye of the reader through the code, good comments

augment carefully chosen variable names, and clear syntax. Doing this shows that you have

thought deeply about the program.

Previous Chapter

11. Programming Problems Using File (1/2)

Next Chapter

II. Recursion

Table of Contents for Intermediate C Programming

Table of Contents for
Intermediate C Programming