20 ms·

* No comments * No line jumps * Cryptic variable names * Magic numbers * Multiple return points in the middle of the function Yeah, this code might be doin

by Mahn 10y ago

* No comments * No line jumps * Cryptic variable names * Magic numbers * Multiple return points in the middle of the function Yeah, this code might be doing good things, but I wouldn't be thrilled to inherit it in a project. I mean it's not bad code per se, we all have written things like this; it's just not something to point at for exemplary code either.

tenken 10y ago
The only numbers I see are 1 and 0. Surely, you don't mean we should redefine 1 and 0!? :P Those numbers are hardly magic. The function comment header describes the purpose of the major variables used in the function. While the variables names may seem cryptic, they appear of a consistant format (within the function) so I bet the larger codebase is equally consistent in their usage -- and adapting to the codebases convention would be made easier.
- e12e 10y ago
  It's a little compact for my taste (eg: the mulitple early returns on error, I think I'd like a blank line after a return, to make it stand out a bit more -- but I'm not sure. I don't write C on a daily basis). The only other thing that strikes me is the convoluted calculation of nBytes, from (sizeof(char * ) + sizeof(i16) + 1) multiplied by the n-argument for resize. Granted nBytes is just used for the custom malloc-call, but I get a little scared with that and the naked mix'n'match of sizeof's in there. It seems like that (and maybe a few of the other things) could've been DEFINE-d in a header, and or factored out to easily in-line-able functions -- that might have provided an (even) clearer picture of what's going on.
- dfox 10y ago
  SQLite has it's roots in Tcl/Tk which is written in the same style. Personally I find it hard to read and sometimes it does not even look like C to me, but it is very consistent. Although there are places in Tcl/Tk ecosystem where using LISP bracing style (ie. last line of function being " return xFoo}}}};") in C seems acceptable.

by Mahn 10y ago

tenken 10y ago

The only numbers I see are 1 and 0. Surely, you don't mean we should redefine 1 and 0!? :P Those numbers are hardly magic. The function comment header describes the purpose of the major variables used in the function. While the variables names may seem cryptic, they appear of a consistant format (within the function) so I bet the larger codebase is equally consistent in their usage -- and adapting to the codebases convention would be made easier.

e12e 10y ago
It's a little compact for my taste (eg: the mulitple early returns on error, I think I'd like a blank line after a return, to make it stand out a bit more -- but I'm not sure. I don't write C on a daily basis). The only other thing that strikes me is the convoluted calculation of nBytes, from (sizeof(char * ) + sizeof(i16) + 1) multiplied by the n-argument for resize. Granted nBytes is just used for the custom malloc-call, but I get a little scared with that and the naked mix'n'match of sizeof's in there. It seems like that (and maybe a few of the other things) could've been DEFINE-d in a header, and or factored out to easily in-line-able functions -- that might have provided an (even) clearer picture of what's going on.
dfox 10y ago
SQLite has it's roots in Tcl/Tk which is written in the same style. Personally I find it hard to read and sometimes it does not even look like C to me, but it is very consistent. Although there are places in Tcl/Tk ecosystem where using LISP bracing style (ie. last line of function being " return xFoo}}}};") in C seems acceptable.