Enrico Tassi Homepage / C code

How (not) to bias the correction of projects

Some stupid details can really change the impression of people on every subject. I try to evaluate projects with a rigid meter, but since I'm a human, these are things that may change (a bit) my impression on your work.

Thinks I really dislike

• Raw hexadecimal constants here and there (use #define and a meaningful name).
• Conditional expressions that do not fit the screen (define a function/macro with a meaningful name instead).
• Lines so long that even with full screen window and a reasonable font size do not fit. Please, break them. 80 characters is a reasonable bound and all text editors can break the lines almost automatically.
• Badly written Makefile (please, use variable to make paths easy to change).

Things I really don't care

• Indentation and code formatting: if it is coherent... it is OK.
• Naming policy: use one, and only one, and I'll like it.
• File format: both dos/unix EOL are fine, but choose one and be consistent.

Things I really like

• Precise documentation, that helps me in understanding what you did and how. If you did something different from the basic requested implementation, please detail and motivate it.