STYLE SHEET

CS 163: Data Structures

 

 

 

Design Write-up

With each program, submit a file (e.g., design1.txt) that describes the major design considerations encountered, and all data structures and algorithms used. It must be a plain text document. You must have your name in this file.

 

• The design write-up must be written in English using complete sentences. Each major design issue should be described. In the design considerations, discuss what the main design considerations are, why they are the main design considerations, how you solved them, and why you solved the way you did. Think in terms of analyzing your solution!

 

• Answer the following questions in your design write-up:

1) How well did the data structure selected perform for the assigned application?

2) Would a different data structure work better? If so, which one and why...

3) What was efficient about your design and use of the data structure?

4) What was not efficient?

5) What would you do differently if you had more time to solve the problem?

 

• Please note that your design write-up should not look like C++ code; words such as "cin", "cout", "++", "--" should not be part of your design document. Instead, describe the major tasks that your program accomplishes. Any design document submitted which looks identical to C++ code will not be accepted.

 

• Your design write-up should be at least one page in length or at least 600 words.

 

Documentation of Source Code

Requirements for internal documentation in the form of comments are listed below. 

1.  A heading explaining what the program does and listing the name of the program author, date, class number and program number.  A heading must be supplied indicating the purpose of the entire program; in addition, each separate function should have a heading describing it purpose and arguments.

 

2.  Each file should also have a heading, explaining the purpose of that module and the listing the filename (this is important!).

 

3.  A comment following each variable declaration telling what it will be used for.

 

4.  Comments to explain any program action whose purpose is not obvious to anyone who reads the code.

 

5. Use mnemonic names for identifiers that relate to their purpose.


 

Requirements

The following are source code format requirements.

1.  A consistent pattern of indentation.  See the attached C++ style requirement for examples.

 

2.  White space (blank lines) to separate program sections.  At least three lines of white space must separate functions.

 

3.  In your program heading, explicitly list the input data to your program, following the header "INPUT:". This should include the source and format for the data being input to the program.

 

4. Also in your program heading, explicitly list the output that will result from running your program, following the header "OUTPUT:". This should include the nature and format for the program results.

 

5. For functions, make sure to include a header comment for each function; this should explain the purpose of the function as well as describe the INPUT and OUTPUT parameters.

 

6. NEVER use global variables in these programs!

 

7. Avoid the use of exit, continue, or break to alter the flow of control of loops

 

8. Avoid using while(1) type of loop control

 

9. NEVER use the string class in CS163 – instead use arrays of characters

 

10. Abstract Data Types should NEVER prompt the user or read information in. All information should be passed from the client program or application

 

11. Abstract Data Types should NEVER display error messages but instead supply success/fail information back to the calling routine.

 

 

PROGRAM RESULTS

• Output must be formatted so that it is self-explanatory and not irritating to read.

 

• ALL INTERACTIVE INPUT MUST be echoed.

 

Files to Submit with Each Assignment

 

1. Algorithm

 

2.  Header files   (.h files)

-- comment the beginning of this file with:

a) your name, class number, project number, name of the file

b) a description of what this file contains (purpose of the header file)

c) structures, classes, prototypes definitions

 

3.  Implementation files of your classes  (.cpp files)

-- comment the beginning of this file with:

a) your name, class number, project number, name of the file

b) a description of what this file contains (purpose of the header file)

 

-- place the code in the following order (for a class' implementation):

a) constructors -- default, ones with arguments

b) destructor (if you have one)

c) remaining member functions

 

-- if you destructor calls another function -- then place that function immediately after the destructor

 

4. Implementation of the client/application program (i.e., the main), (other .cpp files)

 

 

IMPORTANT NOTES:

1.       Submit your program to the D2L Dropbox for the appropriate assignment.

2.       If you submit your program to the wrong dropbox, it will not be graded correctly

3.       It is best to wait to submit your program to the D2L dropbox until you are satisfied. Only one version of your program will be graded.

4.       If you submit a program to the D2L dropbox after the late due date, the grader is under no obligation to grade the assignment unless you have instructor approval.

5.       With D2L, you must first upload the file(s) and then select the “Submit” button. Forgetting to do so will cause the uploaded files to be lost.

6. As a precaution, ALSO email your programs to: karlafgr@cs.pdx.edu  The grader will be using the D2L dropbox, but if there is a problem with D2L, emailing your programs to karlafgr will ensure that you get full credit, as appropriate. However, please do not send requests or questions to this email as it is not monitored.

 

Always keep a backup of your programs!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

 

REMINDERS: Every program must have a comment at the beginning with your first and last name, the class (CS163), and the assignment number. This is essential!