The code follows a truth table approach； which could be considered following a set of conditions and then acting on the conditions。 For example； a state could be defined as If A = X； and B ！= Y then do C。 To process the mand…line arguments； we define all of the possible states and then all of the possible resulting actions。 ■Note By going through each and every variation of the mand…line arguments in a sequential manner； I am ensuring that I am testing for each situation。 When running various tests and then acting on the tests； you need to be explicit and redundant； because the code is easier to follow。 All too often； programmers take shortcuts and miss a particular test； causing a bug that is extremely hard to track down。 The first If block tests if the argument count is zero； then the second tests if there is a single argument； and so on。 Let’s look at the first test： …………………………………………………………Page 281…………………………………………………………… CH A PT E R 1 0 ■ L E A R N I N G A B O U T P E R S IS T E N CE 259 If args。Length = 0 Then reader = Console。In writer = Console。Out 。。。 End If Here； the source and destination of the lottery number data stream are the console input and output streams。 The code assigns the reader and writer variables。 If the mand line had no arguments or if one of the mand…line argument tests has been verified； the IProcessor implementation is called： writer。Write（processor。Process（reader。ReadToEnd（））） The code directly executes writer。Write（）； processor。Process（）； and reader。ReadToEnd（）。 There is no verification of whether writer； processor； or reader point to actual object instances。 There could be a case for adding code that verifies if processor references an actual object instance； but there is absolutely no point to adding code to verify if writer and reader reference actual object instances。 Doing so would imply that your truth test block is inplete and you have not thought through all the permutations that assign writer and reader。 Let’s look at the next truth test； which indicates that there is one mand…line argument。 When there is one mand…line argument； you need to verify which of the two mand line variations it is： TestProcessor。exe …help or： TextProcessor。exe lotto。txt The first variation has an explicit mand…line parameter …help。 The second variation is the identifier of a file that contains the input data。 Thus； the second If block contains another If block to test another aspect of the truth test： ElseIf args。Length = 1 Then If args（0） = 〃…help〃 Then Bootstrap。DisplayHelp（） Return End If reader = File。OpenText（args（0）） writer = Console。Out When testing for the …help argument； immediately after calling DisplayHelp（）； you must use the Return keyword。 This is extremely important because； when the console application calls DisplayHelp（）； it is saying； “I don’t care where the input or output data is ing from since I am doing something else and thus must stop processing。” If you were to continue processing； the writer and reader could reference invalid states and cause an exception to be generated。 If all tests have been tried and failed； then the final Else calls the method DisplayHelp（） to indicate that the mand line is incorrect； and the help shows the correct mand line。 Doing a plete test and debug of the console application is difficult because of the streaming facilities。 When you stream data from one process to another； a process is started …………………………………………………………Page 282…………………………………………………………… 260 CH AP T E R 1 0 ■ L E A R N I N G A B OU T P E R S IS TE N CE and stopped without an easy way for the debugger to jump in between。 Thus； to be able to debug and verify if everything works； another strategy is needed。 The solution is to use prepro cessor directives （discussed in Chapter 6）； like the following。 #If DEBUG_OUTPUT Then Console。WriteLine（〃Argument count（〃 & args。Length & 〃）〃） For Each argument as String in args Console。WriteLine（〃Argument （〃 & argument & 〃）〃） Next #End If The directive code is executed if DEBUG_OUTPUT is defined。 In the example； the argument count and arguments are output to the console。 To activate the directive； the item DEBUG_OUTPUT is defined at the project level or near the top of the source code file。 The shell is plete； and all that remains is the implementation of the text processor。 Implementing the TextProcessor Application In implementing the text processor； the problem that confronts us is how to fix a data stream so that it is consistent。 The main reasons for data inconsistencies are human error and carelessness。 Figure 10…3 shows what is displayed when you load the lottery number text file in Notepad。 It seems very obvious that something is not right with this file。 Figure 10…3。 The lottery text file loaded in Notepad …………………………………………………………Page 283…………………………………………………………… CH A PT E R 1 0 ■ L E A R N I N G A B O U T P E R S IS T E N CE 261 However； what appears wrong in the Notepad display is not the real problem。 When the text file is loaded using another text editor； such as Vim； the text is displayed as shown in Figure 10…4。