|
1 |
| - Coding styles are like assholes, everyone has one and no one likes anyone elses." |
| 1 | + "Coding styles are like assholes, everyone has one and no one likes anyone elses." |
2 | 2 | --Eric Warmenhoven
|
3 | 3 |
|
4 | 4 | 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)
|
179 | 179 | ...
|
180 | 180 | }
|
181 | 181 |
|
| 182 | +As a general guideline, functions shouldn't usually be much more than 30-50 |
| 183 | +lines. Above, the general algorithm won't be easily apparent, and you're |
| 184 | +probably missing some factoring/restructuring opportunity. |
| 185 | + |
182 | 186 | === STRUCTS / UNIONS / ENUMS ===
|
183 | 187 |
|
184 | 188 | Use typedefs when defining structs. The type should be named something_t.
|
@@ -238,6 +242,15 @@ Use //, it's shorter:
|
238 | 242 | them anyway - we have version control, it's easy to fetch old code if needed,
|
239 | 243 | so avoid committing commented out chunks of code. The same goes for #if 0.
|
240 | 244 |
|
| 245 | +=== FILE === |
| 246 | + |
| 247 | +Please use common sense and restrain yourself from having a thousands+++ line |
| 248 | +file. Functions in a file should have something *specific* in common. Over time |
| 249 | +sub-categories can arise and should therefore yield to file splitting. |
| 250 | + |
| 251 | +For these reasons, vague and general filenames (e.g. util.*, global.*, misc.*, |
| 252 | +main.*, and the like) should be very limited, if not prohibited. |
| 253 | + |
241 | 254 | === FILE HEADERS ===
|
242 | 255 |
|
243 | 256 | License/description header first:
|
|
0 commit comments