Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Regarding C code, it's perfectly normal to frequently encounter <code>NULL</code> pointer checks, especially when it comes to function arguments. Personally, I prefer to let the caller resolve the situation, as in:</p> <pre><code>if (p == NULL) { /* maybe do some cleanup and then: */ return errcode; } </code></pre> <p>Public functions, i.e. functions that are part of the API, should always check for <code>NULL</code> pointers. Functions that are designated <code>static</code> may IMO drop those checks. And finally, there's always <code>assert()</code>. Those checks can be suppressed by the compiler flag <code>-NDEBUG</code>. I use <code>assert()</code> in <code>static</code> functions instead of <code>if</code>-statements and in "public" functions for tests that reveal that the caller didn't actually understand the API as a whole, e.g. in a linked list lib:</p> <pre><code>void list_print(list **l) { assert(l != NULL); /* no valid list passed by reference can ever be NULL */ if (*l == NULL) /* but it can be empty */ return; /* print list */ } </code></pre> <p><br> As for your second concern, I can see three options:</p> <p>1) leave everything as it is - after all, it's working.</p> <p>2) introduce new functions:</p> <pre><code>int function_1_2a_3(); int function_1_2b_3(); </code></pre> <p>3) introduce new parametrized functions:</p> <pre><code>int function_1_2_3(int type); </code></pre> <p>Personally, I prefer the latter approach, but that is really just a matter of style. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. COWell, as for the NULL-Pointer, I guess I have to get used to that. It's really anoying to see half the code is about NULL-Pointer checking. As for your three option: 1) But it's a pain in the ass to maintance 2) See my Comment above. We have some of this functions. There again DRY is violated, because they are composed by 80% the same code. To sort all that out will create one layer above the next. 3) That would be a possibility, but I fear to create the big one mammut that will be controlled be a myriade of switches, cases and stuff.
      singulars
    2. CO...and it gets *really* annoying if you have an API function checking for `NULL` pointers which passes the arguments to some internal function which checks again, and so on. An expert programmer may be able to drop most of those checks, but for us mortals, it's probably wise to stick with redundancy. Three options: 1) Yep, maintenance easily comes in the way. 2) I don't see a violation of DRY: hide your original functions behind the `static` keyword and only expose your convenience layer, calling those other functions. I would call this approach "elegant". (no space left, see next comment)
      singulars
    3. CO3) It depends on the number of functions that you're trying to hide. If you already feel fear, you are probably right about that, and it's furthermore a bad idea with regard to maintenance. `ioctl()` is a good example of this technique, and a perfect example of a crappy interface.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload