Project Requirements

by: burt rosenberg
at: august 2023

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

• Platform
  • Projects are programming projects, done in C on Unix.
  • All reasonable effort shall be made to make your code platform independent, however your code must work on Ubuntu 22.04.2 LTS.
  • For OSX, use the builtin command line or install Multipass.
  • Multipass (it says on the webpage) also works for Windows.
  • In an Ubuntu shell, no matter how you get one, it might be make is not found. To get your build tools, use
    sudo apt-get install build-essential.
  • OSX is a combination of a Mach Kernel and the FreeBSD Operating System, both of which are Open Source and the combo goes by the name of Darwin. However, the desktop and perhaps management tools are proprietary. So opening up a terminal on Apple is unix.
  • For the terminal on Apple, for missing packages, use Brew. Brew is a package manager, same as apt which is the package manager for Debian derived unices, or yum, which is the package manager for Red Hat derived unices.
  • For Windows, use either Cygwin or WSL.
  • Explore AWS or similar. The class will require proficiency with cloud computing.
  
  
• IDE's and Editors
  • Mea Culpa: I code using BBedit and debug with printf's.
  • Although you can use an IDE, make sure your code and makefiles strip clean of the IDE.
  • I recommend basic facility with vi because when bringing up a new install, a crashed system, or a cloud instance, this might be all you have.
  
  
• Github
  • Your work will kept in a GitHub account associated with you GitHub name.
  • Projects will be submitted through GitHub.
  • Gitbash is helpful for windows users.
  • You can use SSH or Classic Token Authentication.
  
  
• Makefiles
  • You will use Makefiles so that the we can build your projects exactly as you built them.
  • The test suites are all automated and launched from the makefile.
  • A project is not complete without a makefile. Your build is part of code delivery.
  
  
• Test
  • Make test suites for your code.
  • We use test-driven development. Which here means code is stuff that passes explicit tests.
  • Code is never correct. It works as expected on a collection of tests.
  
  
• Coding style
  • Your name and date must be in comments at the top of all files.
  • Use the coding style known as K&R, which is the original style from The C Programming Language.
  • You can use U Chicago Style, which is very acceptable.
    • However, I do use tabs,
    • and my indentation is The One True Brace Style,
    • and I typedef reluctantly.
  • The casing rules to obey,
    • snake_case for variables and function names;
    • CamelCase reserved for structure tags ;
    • SHOUTY_CASE for defines ;
    • Name mangle globals to end in _g.
    • typedef structs with snake_case name mangled to end in _t.
  • Do not declare variables in the middle of a block.
  • Do not use variable length arrays (VLA).
  • Resolve all warnings.
  • The C++ // one-line comment style is ok. (Although it then distinguishes new-lines from other white-space.)
  • A program is written by one person and debugged by many people. The rational for programming style is consideration by those that write for those that debug.

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

author: burton rosenberg
created: 21 aug 2017
update: 30 aug 2023