4 ms·

Cached: https://webcache.googleusercontent.com/search?q=cache:http://www.jarchitect.com/Blog/?p=2392 https://webcache.googleusercontent.com/search?q=cache:http:

by orf 10y ago

Cached: https://webcache.googleusercontent.com/search?q=cache:http://www.jarchitect.com/Blog/?p=2392 https://webcache.googleusercontent.com/search?q=cache:http:/... The post says the first code snippet's variable naming is easy to understand. Really? To me it's unreadable despite ticking all the best practice boxes. I mean there are no comments and all the variable names seem to be as short as possible, it's hard to follow exactly what and why it's doing things to me at least.

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 orf 10y ago

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.