4 ms·

> Looking at his code, it's kind of scary. No comments. Did you ckeck out addresses.5, for example? The source may not be commented, but if he clearly describe

> Looking at his code, it's kind of scary. No comments. Did you ckeck out addresses.5, for example? The source may not be commented, but if he clearly describes his assumptions (he does), source comments are less necessary. > K&R C style declarations. I don't understand what bearing this has on code quality. Do you contend that it leads to bugs?

acqq 12y ago
And the code had to be compiled with the compilers that even in nineties were "old".
- simtel20 12y ago
  I don't think you are right to say "had to be compiled with". It could be compiled with SunOS cc, and the c compilers of other vendors that were crappy and out-of-date. It could also be compiled on the current gcc/egcs etc. that were out. I think it had issues with e.g. the solaris cc because it was a pretty broken and barely used compiler to begin with.
aros 12y ago
Just glancing through the qmail GitHub repository gave me a headache. Plenty of files have 0 comments (not really sure where you see the clearly stated assumptions). In addition, he seems obsessed with 1 letter variables which offer no inclination of their purpose at a glance.
- simtel20 12y ago
  Here's something I did for myself a long time ago: take some of the fundamental code like alloc.c, alloc_re.c, fmt_str.c and str_*.c, and start commenting it yourself. I found that it was so expressive and concise that after a short time the code is very clear and the comments get in the way. The only real noise is that no-one uses SunOS cc anymore and compilers will optimize loops (expanding in place, or doing other magic optimizations when appropriate) so loop-unrolling doesn't apparently buy an increase in performance anymore.
- taeric 12y ago
  And yet he probably wrote code that would be considered objectively better than anything I have ever seen from my large variable name and lots of comments colleagues. Perhaps there is more to it than surface level concerns?
  - aros 12y ago
    You've presented a false dichotomy. You've also not defined what constitutes as "objectively better" when judging code. My original comment was based entirely on readability and maintainability as a third party. I'm sure the author of the code has no issue knowing exactly what is happening and how to fix issues. Imagine someone trying to audit the code. It would take a ton of wasted time just to get up to speed which could be alleviated by, you know, documenting.

acqq 12y ago

And the code had to be compiled with the compilers that even in nineties were "old".

simtel20 12y ago
I don't think you are right to say "had to be compiled with". It could be compiled with SunOS cc, and the c compilers of other vendors that were crappy and out-of-date. It could also be compiled on the current gcc/egcs etc. that were out. I think it had issues with e.g. the solaris cc because it was a pretty broken and barely used compiler to begin with.

aros 12y ago

Just glancing through the qmail GitHub repository gave me a headache. Plenty of files have 0 comments (not really sure where you see the clearly stated assumptions). In addition, he seems obsessed with 1 letter variables which offer no inclination of their purpose at a glance.

simtel20 12y ago
Here's something I did for myself a long time ago: take some of the fundamental code like alloc.c, alloc_re.c, fmt_str.c and str_*.c, and start commenting it yourself. I found that it was so expressive and concise that after a short time the code is very clear and the comments get in the way. The only real noise is that no-one uses SunOS cc anymore and compilers will optimize loops (expanding in place, or doing other magic optimizations when appropriate) so loop-unrolling doesn't apparently buy an increase in performance anymore.
taeric 12y ago
And yet he probably wrote code that would be considered objectively better than anything I have ever seen from my large variable name and lots of comments colleagues. Perhaps there is more to it than surface level concerns?
- aros 12y ago
  You've presented a false dichotomy. You've also not defined what constitutes as "objectively better" when judging code. My original comment was based entirely on readability and maintainability as a third party. I'm sure the author of the code has no issue knowing exactly what is happening and how to fix issues. Imagine someone trying to audit the code. It would take a ton of wasted time just to get up to speed which could be alleviated by, you know, documenting.