cluttered code / too much commented out code.
poor indentation / whitespace.
exceedingly over-commented or under-commented code.
poorly named variables / functions.
hard-coded constants rather than #define'd.
use of *(arr + i) when arr[i] should be used.
poor use of syntax.
e.g. (*structPtr).field rather than structPtr->field)
e.g. comma operator (mis)use.
Inappropriate use of pointer arithmetic to access struct fields when casting can be used..
other bizarre and unconventional ways of accessing pointers / arrays.
Failure to use a library function when one exists, or using the wrong one
e.g. for-loop over string to find char rather than using strchr.Poorly designed function interfaces, e.g. too complex or poorly encapsulated
Redundancy in data or data being copied far more than necessary
Excessive and unnecessary use of globals
Minor algorithmic failures (i.e. doing it the hard way, but not egregious)
Poor decomposition, i.e. - one huge chunk of code
Algorithm is too complex or convoluted, i.e. - does it the really hard way (this would probably be a good place to deduct if they make function calls "up" the layers - that just cannot be a good algorithmic choice...)
Code copying rather than unifying into helper functions that can be reused
Poor data management, i.e. - parallel arrays, information hiding
Unnecessary levels of indirection in variables (void** when void* is all you need, etc.)
Poor / sloppy use of pointer types (using char* / int* with what should be a void*)
use of ptr[0] to dereference a single pointer
Using the heap when the stack is more appropriate (or vice versa), or not freeing heap memory.