SICE Curriculum Portal for Thomas Heffron
Contents

Home
UMKC Curriculum
   FS '96
      CS 101
   SS '01
      CS 201
   FS '01
      CS 191
      CS 281
   WS '02
      CS 291
      EN 304wi
   SS '02
      CS 352
      CS 481
   FS '02
      CS 431
      CS 441
   WS '03
      CS 423
      CS 451
SICE Survival Guide
Personal Experience

contact me @umkc:
tehqnf@umkc.edu
CS441 - Homework #2

Question #1
I agree with Dr. Sebesta that the inclusion of goto statements (or 'uncontrolled jumps') is the most detrimental statements to the readability of a language. Allowing a goto statement can lead to what some refer to as 'spaghetti code' where the flow of the program can jump all over the text of source code - a frustrating situation in large programs. This would be similar to shuffling the pages of a book and telling the reader that they are not allowed to reorder the pages before hand - although it can be read, it takes much more effort and has a greater potential to be read incorrectly, and, thus, not understood properly.
 
By disallowing (or highly discouraging) goto statements, this encourages more organized structure of source code. Although a language can allow the change of flow by using well-structured controls such as for, while, and procedure, allowing the use of gotos puts no restrictions on structure of loops. Therefore, a reader must additionally 'figure out any rules' regarding change in flow before understanding the meaning of the program.
 
Note: While gotos are the statements that are most detrimental, I believe the concept of operator overloading has the potential to cause the most harm. Since not all languages support this idea and a programmer can implement this concept very responsibly, it does not seem to reach the highest level. However, it is very easy for the reader of source code to believe what a given statement should do, but overloading could produce a different result. Thus, the reader does not fully understand the intent of the writer without further investigation.
 
Question #2
Readability - Case-sensitivity requires the reader to be careful of any identifiers that may have the same letters, but different case. If a reader sees chapter (integer type) and Chapter (character string) in the same code, they may need to pause at each instance to double-check which variable is being manipulated - this can slow readability. However, once read properly, the reader understands better which variable is being identified.
 
Writability - Case-sensitivity ensures that the intent of the writer is represented in the code. However, the writer must check that the correct case identifier is used. Incorrect capitalization to an unidentified variable will create a compilation error. Even worse - as in the example above - an incorrect capitalization can reference the wrong (but allowable under the compiler) identifier.
 
Reliability - Case-sensitivity makes the program more reliable. This ensures that the compiler has identified the correct variable to manipulate and that there are not excessive aliases for the same variable. Also, since the intention of the writer is clear(er), the compiler is less complex and more reliable.
 
Question #3
Type declaration statements aid in readability by identifying to the reader which variables will be used (and what type of data they will hold) in the following code. It's similar to a 'list of characters' in a theatrical script. The reader can also identify the scope of the variable by noting when they are declared - variables declared within a procedure definition will usually only be valid within that procedure call.
 
Question #4
My evaluations of LISP and C++ with respect to readability, writability, and reliability.
 
Question #5
My evaluations of LISP and C++ with respect to total cost defined by Sebesta