5 ms·

I've read that Redis (https://github.com/antirez/redis https://github.com/antirez/redis) has well written code, in C.

sidlls 10y ago
It is very good.
nodesocket 10y ago
I've also heard that Redis is incredibly well written. However, is it common for production C code to have a single file with 5,300+ lines? https://github.com/antirez/redis/blob/4.0/src/cluster.c https://github.com/antirez/redis/blob/4.0/src/cluster.c
- brongondwana 10y ago
  https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/imapd.c#L14152 https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/im... cough Yep
- exDM69 10y ago
  > However, is it common for production C code to have a single file with 5,300+ lines? It's definitely not uncommon, but yes, that file is on the long side. However, it is rather clean and well-organized. It may be due to the poor module system (header files) of C where you end up making files slightly longer than ideal because splitting into two files means also adding some header files and thus adding to the maintenance burden. When writing C code, I usually strive to put a whole "module" in a single file, so that no "private" interfaces have to be put in header files. Everything that needs to be exposed in order to test a module goes in the public interface. It's a tradeoff and C being C doesn't help (and C++ wouldn't really help here IMO), but I see nothing wrong with the file you picked. It's a bit long but it looks well done to my C programmer eyes.
- chillingeffect 10y ago
  Right off the bat, I see multiple instances of str* functions where strn* functions should be used. I'm also wondering about this variable "server" which seems to have an unknown definition. There are lots of gotos, and many other deferred high-quality conventions, such as explicit parenthesis in comparisons, re-ordered fields in comparisons, chains of else ifs, where a switch would be preferable. I also see lots of prototypes (all?!) defined at the top of the file instead of in a header file. They could be made static. Also, the generic type "int" isn't a good idea because it can change, it helps avoid porting problems to specify the size (int32_t, uint64_t, etc.) And the memcpy()'s should be changed to memcpy_s(). On the bright side, the comments are quite good and plentiful. Refreshing!

It is very good.

I've also heard that Redis is incredibly well written. However, is it common for production C code to have a single file with 5,300+ lines? https://github.com/antirez/redis/blob/4.0/src/cluster.c https://github.com/antirez/redis/blob/4.0/src/cluster.c

brongondwana 10y ago
https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/imapd.c#L14152 https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/im... cough Yep
exDM69 10y ago
> However, is it common for production C code to have a single file with 5,300+ lines? It's definitely not uncommon, but yes, that file is on the long side. However, it is rather clean and well-organized. It may be due to the poor module system (header files) of C where you end up making files slightly longer than ideal because splitting into two files means also adding some header files and thus adding to the maintenance burden. When writing C code, I usually strive to put a whole "module" in a single file, so that no "private" interfaces have to be put in header files. Everything that needs to be exposed in order to test a module goes in the public interface. It's a tradeoff and C being C doesn't help (and C++ wouldn't really help here IMO), but I see nothing wrong with the file you picked. It's a bit long but it looks well done to my C programmer eyes.
chillingeffect 10y ago
Right off the bat, I see multiple instances of str* functions where strn* functions should be used. I'm also wondering about this variable "server" which seems to have an unknown definition. There are lots of gotos, and many other deferred high-quality conventions, such as explicit parenthesis in comparisons, re-ordered fields in comparisons, chains of else ifs, where a switch would be preferable. I also see lots of prototypes (all?!) defined at the top of the file instead of in a header file. They could be made static. Also, the generic type "int" isn't a good idea because it can change, it helps avoid porting problems to specify the size (int32_t, uint64_t, etc.) And the memcpy()'s should be changed to memcpy_s(). On the bright side, the comments are quite good and plentiful. Refreshing!