4 ms·

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c http://git.musl-libc.org/cgit/musl/tree/src/network/getadd

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

alkonaut 11y ago
It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros. But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming? Who is it that writes code like this? Why isn't code like this rejected by a maintainer with "split this into at least smaller 5 functions and comment anything non-obvious"? Edit: looking again it's actually not that bad, it does have two lookups already broken out and a lot of the verbosity is just field assignment. Would be happy with a dozen lines of comments and a split into 2-3 functions.
- AndyKelley 11y ago
  I feel like comments are extremely valuable in API documentation, but not so much in the implementation. When you're reading an API you want to understand how it works without cracking open the source. When you're looking at an implementation it is your duty to load the source into your comprehension, at which point comments become irrelevant, or worse, misleading.
  - alkonaut 11y ago
    Here is how much comments is actually needed: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=b995d95a5943785be3ab862b2d3276f3b4a22481 https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdi...
- spc476 11y ago
  As long as the function is doing one thing conceptually, I don't see the benefit of breaking it up into multiple routines just because it's too long (for some arbitrary length). Not only do you have the cognitive overhead of trying to come up with a name [1], but passing in all the required parameters to the function. And for this function, I personally don't see any good "breaking points". At work, I have to deal with a code base where code is split up like that, and it's a royal pain to follow, and the resulting functions aren't usable by anything else. [1] The two hardest problems in computer science is cache invalidation, naming things, and off by one errors.
  - alkonaut 11y ago
    It's true that a function in an expressive language can be 10 lines, which in C is 70 lines just because of verbosity (repeated assigns instead of constructors and so on). So while the threshold is certainly higher in C, this is still too large. It does 3-4 things conceptually but 2 (lookups) are already broken out. I can see at least one opportunity more for extracting a function. It's important not least because of testing.
    - spc476 11y ago
      I'd like to know what you would extract out to its own function, because I certainly don't seen anything worth making its own function.
      - alkonaut 11y ago
        Maybe it's just my aversion to C (and procedural) in general but I think assigning 3 fields of the same struct in succession as a sign that you are making an inline constructor that should be explicit. The chunk I meant looked like a possibility though was the hint bit. The point of smaller code is testability. It's worth even making it somewhat harder to read. If a test makes three things in succession that in their own functions would have required 3 tests each, the aggregated do-everything function requires much more than the 9 test cases. So dividing the method in two, even if arbitrary and bad for readability can have a positive impact since the total code volume is reduced a lot. All of this ^ only applies if the code actually has tests. If not - then don't divide arbitrarily if it reduces readability at all. But then again without tests you have bigger problems than readability...

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

alkonaut 11y ago

It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros. But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming? Who is it that writes code like this? Why isn't code like this rejected by a maintainer with "split this into at least smaller 5 functions and comment anything non-obvious"? Edit: looking again it's actually not that bad, it does have two lookups already broken out and a lot of the verbosity is just field assignment. Would be happy with a dozen lines of comments and a split into 2-3 functions.

AndyKelley 11y ago
I feel like comments are extremely valuable in API documentation, but not so much in the implementation. When you're reading an API you want to understand how it works without cracking open the source. When you're looking at an implementation it is your duty to load the source into your comprehension, at which point comments become irrelevant, or worse, misleading.
- alkonaut 11y ago
  Here is how much comments is actually needed: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=b995d95a5943785be3ab862b2d3276f3b4a22481 https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdi...
spc476 11y ago
As long as the function is doing one thing conceptually, I don't see the benefit of breaking it up into multiple routines just because it's too long (for some arbitrary length). Not only do you have the cognitive overhead of trying to come up with a name [1], but passing in all the required parameters to the function. And for this function, I personally don't see any good "breaking points". At work, I have to deal with a code base where code is split up like that, and it's a royal pain to follow, and the resulting functions aren't usable by anything else. [1] The two hardest problems in computer science is cache invalidation, naming things, and off by one errors.
- alkonaut 11y ago
  It's true that a function in an expressive language can be 10 lines, which in C is 70 lines just because of verbosity (repeated assigns instead of constructors and so on). So while the threshold is certainly higher in C, this is still too large. It does 3-4 things conceptually but 2 (lookups) are already broken out. I can see at least one opportunity more for extracting a function. It's important not least because of testing.
  - spc476 11y ago
    I'd like to know what you would extract out to its own function, because I certainly don't seen anything worth making its own function.
    - alkonaut 11y ago
      Maybe it's just my aversion to C (and procedural) in general but I think assigning 3 fields of the same struct in succession as a sign that you are making an inline constructor that should be explicit. The chunk I meant looked like a possibility though was the hint bit. The point of smaller code is testability. It's worth even making it somewhat harder to read. If a test makes three things in succession that in their own functions would have required 3 tests each, the aggregated do-everything function requires much more than the 9 test cases. So dividing the method in two, even if arbitrary and bad for readability can have a positive impact since the total code volume is reduced a lot. All of this ^ only applies if the code actually has tests. If not - then don't divide arbitrarily if it reduces readability at all. But then again without tests you have bigger problems than readability...