Comments on Assignments and Tests

Assignment 1

The comma-separated numbers penned on the front of your assignment are the marks awarded for (in order):

• Accurate Assignment Label (2 marks)
• Table of Contents (1 mark)
• Layout/Formatting (3 marks)
• Coding/Algorithms (3 marks)

• Testing (3 marks)

• Bonus Marks for excellence in any of the above (2 bonus marks)

The maximum mark is 12.    The weighting factor for this assignment is posted elsewhere.

Some notable errors or style problems in Assignment 1:

• Ignoring the assignment hand-in specifications.  (No assignment label, no student number, etc.)
• Mis-aligned line printer output with page breaks in mid-page.
• Printing over the perforations instead of paginating output.
• Poor quality line printer output; unreadable print quality.
• Printing listings with TAB settings or fonts that mis-aligned code.
• Stapling that hides code or output, making it unreadable.
• Not doing what the function specifications said to do.  (E.g. forgetting to put '\0' on the end of the buffer.)
• Doing more than the function specifications said to do.  (E.g. putting '\0' after every character in bf_addch().)
• Doing no testing, or claming testing but supplying no test output.
• Putting a second character into the buffer (e.g. '\0') without checking to make sure there was room.  (bf_addch() would have done this perfectly...)
• Putting comments on every line of code, instead of comment blocks in front of code blocks.  Programming languages are not like assembler; not every line needs a comment.
• Casting integer to character when not required.
• Claiming that you wrote main() and eprintf(), when they were actually copied from the assignment specification.
• Putting '\n' and EOF into the buffer, and/or coding bf_addch() not to add these characters.
• Using "else" clauses on if statements that return or exit.
• Being vague in error messages, instead of printing exactly what is wrong.
• Reading a character before starting a loop, instead of coding the getchar() into the loop itself.
• Duplicating code, including arithmetic expressions, return statements, and error testing.

Midterm #1

Four students wrote the midterm who are not registered with my marking system using my Web registration form.  Gentlemen: What are you waiting for?

Common errors on Midterm 1:

• Not understanding what "other" means in a state diagram and transition table.

Assignment 2

The comma-separated numbers penned on the front of your assignment are the marks awarded for (in order):

• Accurate Assignment Label (2 marks)
• Table of Contents (1 mark)
• Layout/Formatting (3 marks)
• Coding/Algorithms (3 marks)

• Testing (3 marks)

• Bonus Marks for excellence in any of the above (maximum of 2 bonus marks)

The maximum mark is 12.   The weighting factor for this assignment is posted elsewhere.

Some notable errors or style problems in Assignment 2:

• Putting code or #include directives above the header.   This separates these from the rest of the code.
• Using strcmp() on the return value of modestr() or fopenmode() to determine how a file was opened, rather than simply checking the mode variable.
• Failing to stop stripping white space when you reached the beginning of the buffer.
• Failing to handle empty file names when stripping white space.  (Walking off the front of the buffer.)
• Failing to handle input that is only white space.
• Issuing prompts on standard output (where they get lost, if you redirect output), instead of prompting on standard error (which is almost always the terminal).
• Confusing a NULL pointer with a '\0' (NUL) character.
• Thinking that a file name that starts with a dash is the same as a file name that is a dash.
• Removing spaces inside file names, instead of just at the start and end.
• Not following the exact specification for my_open(), e.g. prompting without checking to see if the file name is already supplied, or failing to return on an empty file name.
• Failing to use strerror() to print the reason why the file could not be opened.
• Issuing vague error messages that don't really tell you what is wrong with your code.
• Not choosing the right kind of loop:  while vs. do/while.
• Writing two lines of code where one would do, e.g. buf[cursize] = ch; cursize++;
• Not testing that your white space stripping actually worked on different file names, including file names with blanks in them (Win95).
• Not reading your own test output to see the errors displayed there.
• Writing a lot of unnecessary pseudo-code.  (See the assignment requirements for details.)
• Writing four lines of code to test if stdin is a terminal, where one line would do.

Assignment 3

• You earn marks for good code (+4 marks), and good testing (+4 marks).
• You lose marks for an inaccurate or missing Assignment Label (-1 mark), a missing Table of Contents (-1 mark), a missing Transition Diagram (-1 mark), or for poor layout or formatting of your submission (-2 marks).
• You may earn one or two bonus marks if your assignment shows excellence in coding or testing.
• The maximum mark is 8.   The weighting factor for this assignment is posted elsewhere.

• I only marked the part of your submission that I requested.  Excessive hand-in paper lost you a mark, since it wasn't what the assignment specifications requested.
• When I provide specifications for a function, use the specifications as the start of your purpose/algorithm.  Students that deleted my specifications and invented their own often implemented the wrong things.
• In the next_state() function, the value of "other" does not depend on the state you are in.  It means "other than the character classes specifically mentioned in the transition table".
• Be clear on which characters get saved in the lexeme.  Do not save all the characters.  Use the current and next states to decide which characters to save; do not test the character itself.
• Note that the underscore is treated exactly the same way as a letter; so, don't have a separate row or column in your state table for it.
• Use exit(EXIT_FAILURE), not exit(1).  Different operating systems have different ideas about what is success and what is failure.
• Code such as the following is incorrect:

if ( p == NULL )
   eprintf("%s is a null pointer\n", p);
if ( p == NULL )
   eprintf("Bad buffer: %d %d\n", p->maxsize, p->cursize);

Assignment 4

The three comma-separated numbers penned on the front of your assignment are the marks awarded for (in order):

• 4 marks: 1 for DFA diagram, 1 for Transition Table, 1 for TokenType enum, 1 for using a4test.txt as a text file
• 5 marks for code quality and layout.
• 3 marks for a testing strategy, good test files, and test output.
• The maximum mark is 12/12.  The weighting factor for this assignment is posted elsewhere.

• When you find yourself writing a tangled mess of Boolean return values, stop for a moment.  Try to find a way to simplify the mess.
• Know how to write a correct state diagram, properly labelled.
• A test strategy means you thought about what different types of test files would show that your code worked, and you ran those tests and gave samples of the output for each of the tests.  And/or you wanted to make sure that all your error messages worked, so you invented a test file or set of test files that had every possible type of error in it.
• Note that running five similar input files (e.g. program source code) simply tests the same thing five times; it doesn't test five different things.
• Don't hand in things that aren't specified as assignment deliverables.
• Do hand in things that are specified as assignment deliverables.

Assignment 5

• You earned one mark each for handing in:  The code for the two functions, the state diagram, and the translation scheme.  Maximum: three marks.    The weighting factor for this assignment is posted elsewhere.
• Perfect marks only means you handed everything in.  Read my comments to discover what might need fixing.
• Many people handed in far more than the deliverables required.  Don't waste your time!
• Translation Schemes:
  • Actions for productions that contain loops (repeated terms) must appear inside the loops, not after the loops.
  • You must push things before you can pop them.
  • It makes little sense to push punctuation tokens such as MUL, SEMI, DIV, EQU, etc.
  • If a production pops something and doesn't push anything back, the non-terminal for that production doesn't leave anything on the stack.  That non-terminal can't be followed by a pop in other productions.
  • Not all productions require push/pop actions.  What is the production trying to do?   Add?  Negate?  The actions should perform the intended semantic actions.
• Panic Mode:
  • The top-level, root parsing function is program(), not parser().
  • The assignment specification said that program() must return an integer: the count of failed statements.
  • Don't write code for behaviour that is not given in the specifications for the functions.
  • No output was required for this assignment.
• State Diagrams:
  • A State Table is not a Diagram.  No table was required in this assignment.
  • Unlabelled edges in the diagram are mistakes that will cost you marks on a test.
  • Remember to mark your push-back (ungetc) states and label them as such.
  • You must only skip leading whitespace in the START state.  Junk characters should be collected into a JUNK token and returned to the Parser.
  • Edges must be labelled with single characters or character classes (such as "digit" or "letter"), not with unknown symbols such as ID, UINT, PRINT, etc.
  • Edges must be arrows, indicating which direction to move when the indicated character is seen.
  • EOF may end a number or an identifier, causing an "other" transition to the GOTID or GOTINT states, not to the GOTEOF state.
  • The only transition to the GOTEOF state should be from the START state.
  • If a string ends at EOF (missing closing quote), your DFA should transfer to an accepting state that returns an error token of some sort.  The EOF might come while collecting characters or while processing an escape.

Assignment 6

The three comma-separated numbers penned on the front of your assignment are the marks awarded for (in order):

• 5 marks for the quality of your a5test.txt test file output.  Is the output correct?  Are all the lines printed?  This file has no errors.
• 5 marks for the rest of your testing strategy, your choice of good test files, your excellent error messages, and your other test output (in addition to a5test.txt).   If you are unable to get any output, describe and give examples of the test files you would have used.
• 5 marks for code quality and layout.
• BONUS: Using the mem package and getting a "clean" run on a5test.txt and your other test files.
• The maximum mark is 15/15.  The weighting factor for this assignment is posted elsewhere.
• Marks will be deducted for incorrect assignment submission format (missing name, student number, diskette label, source file headers, function headers, etc.)

Assignment 7

The three comma-separated numbers penned on the front of your assignment are the marks awarded for (in order):

• 5 marks for the quality of your a7test.txt test file output.  Is the output correct?  Do the error messages print the file name, line number, and token causing the error?  Are all the errors detected?
• 5 marks for the rest of your testing strategy, your choice of good test files, and your other test output (in addition to a7test.txt).  If you are unable to get any output, describe and give examples of the test files you would have used.
• 5 marks for code quality and layout.
• BONUS: Using the mem package and getting a "clean" run on a7test.txt and your other test files.
• The maximum mark is 10/10.  This is a bonus assignment.
• Marks will be deducted for incorrect assignment submission format (missing name, student number, diskette label, source file headers, function headers, etc.)
• Note: Read the requirements!