Note: Some of these requirements may apply to concepts not yet covered, depending on what point in the semester you are reading this at. In this class, you will primarily be writing C code, but you may also write some Bash and Python scripts. For any python coding, you should refer to my 110 python style guide.
You are required to have a header comment at the beginning of every C file or shell script that you submit for assignments in this class.
The header file should at minimum include your name, course, and a several-sentence description of the purpose of the file.
This includes .c files and .sh files.
As you might expect, the exact way in which one writes comments for each of these languages differs, so use the appropriate commenting format.
Every variable, function, struct, or other programmer-named entity should have a descriptive and meaningful name.
You should avoid 1-letter or other ultra-short variable names, with a few exceptions (for example, i and j for index variables).
You may choose any commonly-used naming convention (eg: snake_case, camelCase).
However, you must be consistent with what you choose.
You should not intermix camelCase functions and snake_case functions in the same codebase.
You may choose to use different conventions for different categories of items though.
For example, you may choose to name functions with snake_case and name local variables with camelCase.
Any preprocessor definitions should be named with CAPS.
Every .c or .h file should have a header comment at the very top.
You should use a multi-line comment, and include your name, course, and 1+ paragraph description of the purpose of the program.
Every function other than main must have a detailed function-level comment.
The comment should use a multi-line comment (/** ... */) and should go immediately above the function definition.
The comment must provide an overview of what the function’s purpose is, and must clearly document the parameter(s) and return value(s).
You also must use a consistent style / formatting amongst the comments for a given project.
It is also expected that you leave inline comments on any code that is not easy for another human (or grader) to understand just by looking at it for a few seconds.
After the point in the semester when malloc and free are introduced, every program that you turn in should have no memory leaks whatsoever.
You may check for memory leakage with the valgrind tool.
Every program that you turn in for this course must be able to compile with gcc on lectura.
The -Wall and -Werror must always be used.
-Wall enables all warnings, and -Werror turns all warnings into errors.
This will help / force you to write better C code :).
The assignment specifications may have additional rules about particular compilation flags to use, and those must be followed in addition to these.
You may not use any C libraries other than the C standard library. Thus, the only header files you are allowed to include (other than your own or ones the instructor may provide) are these: https://en.cppreference.com/w/c/header. Some assignment specs may give additional restrictions, so pay attention to those too.
All code should be compiled with C version C11.
For this, you should use the argument -sdt=c11 for gcc.
The requirements for bash scripts are a bit looser than for C or python scripts.
You should always include a header comment with name, course, and description of program, and you should include inline comments throughout.
Non-environment variables should be named with lower-case letters.
You should work to keep your scripts well organized and as easy to read and understand as possible.
The scripts that you write should be runnable on lectura with the bash shell.
Every script should include a #! at the top.