mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2025-01-25 01:22:23 +08:00
Ooops, we forgot a few details
This commit is contained in:
parent
4fc25350c2
commit
6620e46b00
1 changed files with 14 additions and 1 deletions
15
HACKING.txt
15
HACKING.txt
|
@ -1,4 +1,4 @@
|
|||
Coding styles are like assholes, everyone has one and no one likes anyone elses."
|
||||
"Coding styles are like assholes, everyone has one and no one likes anyone elses."
|
||||
--Eric Warmenhoven
|
||||
|
||||
The Proxmark3 codebase is pretty messy and in the process of being cleaned up,
|
||||
|
@ -179,6 +179,10 @@ static void hexdump(void *buf, size_t len)
|
|||
...
|
||||
}
|
||||
|
||||
As a general guideline, functions shouldn't usually be much more than 30-50
|
||||
lines. Above, the general algorithm won't be easily apparent, and you're
|
||||
probably missing some factoring/restructuring opportunity.
|
||||
|
||||
=== STRUCTS / UNIONS / ENUMS ===
|
||||
|
||||
Use typedefs when defining structs. The type should be named something_t.
|
||||
|
@ -238,6 +242,15 @@ Use //, it's shorter:
|
|||
them anyway - we have version control, it's easy to fetch old code if needed,
|
||||
so avoid committing commented out chunks of code. The same goes for #if 0.
|
||||
|
||||
=== FILE ===
|
||||
|
||||
Please use common sense and restrain yourself from having a thousands+++ line
|
||||
file. Functions in a file should have something *specific* in common. Over time
|
||||
sub-categories can arise and should therefore yield to file splitting.
|
||||
|
||||
For these reasons, vague and general filenames (e.g. util.*, global.*, misc.*,
|
||||
main.*, and the like) should be very limited, if not prohibited.
|
||||
|
||||
=== FILE HEADERS ===
|
||||
|
||||
License/description header first:
|
||||
|
|
Loading…
Reference in a new issue