Project Requirements

by: burt rosenberg
at: april 2020

These general remarks apply to how the do the projects for csc424. Please abide carefully.

General Requirements:

• Projects are programming projects, done in C on Unix.
• You will work on AWS EC2, with the current Ubuntu edition offered.
• Free tier eligible should be ok, for those students that are enjoying their free tier period.
• You will use Makefiles so that the graders and assistants can build your projects from source, and are guided through your test suites.
• You will given some test suites. The performance of your code on these test suits define a basic level of correctness.
• You will make additional test suites for your code, and your code maybe be tested on reasonably considered correctness criteria, beyond those implied in the given test suites. It is expected that you will anticipate these reasonably considered correctness criteria, and your test suites will address those.
• You will share and submit your projects using the departmental subversion site, svn.cs.miami.edu.
• Please refer to my subversion tutorial and the Subversion red book for information about subversion.

• The three properties of a C variable are:
  1. Its type.
  2. Its scope.
  3. Its lifetime.
• And you will know, for every variable at every moment, these three things.

• Thy name and date shall be in comments at the top of all files. I consider this your promise to me that this is your own work, or you have explained the source of the code otherwise.
• Comment what isn't obvious. Comment what confused you when you wrote this code.
• Comment assumptions on parameters at the top of the function block. Consider using assertions.
• Write ANSI C as defined by Kernighan and Ritchie, The C Programming language, 2nd edition..
• Do not declare variables in the middle of a block. Reject this C99 feature.
  • Why: A variable's scope and lifetime should be a block, end of story. Coding is hard enough.
• Use only lower-case in filenames, with exceptions for strong historical precedence: Makefile, README.TXT, maybe a few others. Never distinguish a file by case, and always refer to the file by the chosen case.
  • Why: Not all operating systems are case-sensitive.
• Thou shalt not use Variable Length Arrays (VLA). Reject this C99 feature.
  • Why: You now have traded off easier compile-time errors for more difficult run-time errors. Also, sizeof is now a function call.
• C++ // style comments are ok.
  • Why: They can be wrapped inside of slash-star comments when commenting out code blocks.
• I'm conflicted on the use of zero-length arrays. Harbison and Steele, A C reference manual tells me I'm an outlaw (page 98 of the 5th edition) but I can't seem to care.
• I prefer writing subroutines more basic first, so I don't need forward declarations. I consider this a huge hint to debuggers about what depends on what. I recommend not doing forward declarations unnecessarily.
• Use header files. Consider them as declaring your API. What's in the .h file explains what you intend to be the stable functions and types, as opposed to helper functions that might change.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

author: burton rosenberg
created: 21 aug 2017
update: 18 jan 2024