c
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| c [2015/12/31 02:27] – [Use strncpy() rather than strcpy() if at all possible] admin | c [2020/10/17 03:05] (current) – ↷ Links adapted because of a move operation 114.119.151.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =====Writing | + | ====== Decent |
| I've been writing c for over 30 years, but it can still be a nightmare - the problems are well documented elsewhere. The discipline of writing device drivers for Linux/ | I've been writing c for over 30 years, but it can still be a nightmare - the problems are well documented elsewhere. The discipline of writing device drivers for Linux/ | ||
| ====Single return point==== | ====Single return point==== | ||
| - | Every routine should have a single return point. All possible execution paths go through this point and therefore have the chance to have resources released. The main thing, of course, is to free resources that are no longer needed eg memory that has been malloc()' | + | Every routine should have a single return point. All possible execution paths go through this point and therefore have the chance to have resources released. The main thing, of course, is to free resources that are no longer needed eg memory that has been malloc()' |
| ====Error responses should be close to the failing statement==== | ====Error responses should be close to the failing statement==== | ||
| and not dangling at the end of some huge }}}} block ten pages away!!! Deal with it _now_, to hell with making the Happy Path clearer - the Happy Path is easy, it's the errors that make the thing beastly. | and not dangling at the end of some huge }}}} block ten pages away!!! Deal with it _now_, to hell with making the Happy Path clearer - the Happy Path is easy, it's the errors that make the thing beastly. | ||
| Line 12: | Line 12: | ||
| Do it even when it looks stupidly simple - later, when the routine is made more elaborate, then the logic is in place and you will remember to cleanup: | Do it even when it looks stupidly simple - later, when the routine is made more elaborate, then the logic is in place and you will remember to cleanup: | ||
| - | < | + | < |
| /* @return 0 if file is foobarable. Otherwise 1. | /* @return 0 if file is foobarable. Otherwise 1. | ||
| */ | */ | ||
| Line 75: | Line 75: | ||
| ====Return an error code==== | ====Return an error code==== | ||
| If at all possible, always return an int to indicate success or failure eg. 0 for success, anything else for an error. Or return a pointer on success and NULL on failure. | If at all possible, always return an int to indicate success or failure eg. 0 for success, anything else for an error. Or return a pointer on success and NULL on failure. | ||
| - | ====Document all parameters and return values | + | ====Document all parameters and return values==== |
| Just do it. No, the source code is not enough documentation. And keep it up to date as you code. You might as well use doxygen format in case the employer cultivates a taste for it. | Just do it. No, the source code is not enough documentation. And keep it up to date as you code. You might as well use doxygen format in case the employer cultivates a taste for it. | ||
| ====exit values etc==== | ====exit values etc==== | ||
| Unless you've got a really good excuse, the program should exit(0) on success and non-zero on failure (note that exit code can only be up to 8-bits long). | Unless you've got a really good excuse, the program should exit(0) on success and non-zero on failure (note that exit code can only be up to 8-bits long). | ||
| - | As with [[DecentBash]], the program should send error messages (prefixed with the program name) to stderr, output to stdout. It should recognise -h (no matter what) and possibly --help and print help to stdout (and return 0!). -v and --verbose are also pretty standard. | + | As with [[unixscripts: |
| In fact, why not use argp(3) to make option processing easy? | In fact, why not use argp(3) to make option processing easy? | ||
| Line 85: | Line 85: | ||
| Functions must fit on a single editor page. OK I have a hi-res screen and get 70 lines on it, but that's OK. I also stick to K&R code layout (as above) so more context fits on a single screen. | Functions must fit on a single editor page. OK I have a hi-res screen and get 70 lines on it, but that's OK. I also stick to K&R code layout (as above) so more context fits on a single screen. | ||
| ====valgrind==== | ====valgrind==== | ||
| - | You're not done until valgrind says you're done!! | + | You're not done until valgrind says you're done and your program leaks no memory!! |
| ====Keep it simple==== | ====Keep it simple==== | ||
| - | As Kernighan' | + | As Kernighan is reputed to have said, debugging (and tuning) is twice as hard as coding so if you code to the limit of your ability, then by definition, |
| ====Have it reviewed==== | ====Have it reviewed==== | ||
| - | I've learned so much from having others (contructively) critique my code. | + | I've learned so much from having others (constructively) critique my code. |
| ====Links==== | ====Links==== | ||
| Here's someone who thinks the same way: | Here's someone who thinks the same way: | ||
c.1451554059.txt.gz · Last modified: 2015/12/31 02:27 by admin