Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/.clang-tidy | ||
---|---|---|
31 | Please keep alphabet order. |
I am not against this, but it's not clear to me that this really increases readability that much, since 50% of the changes suggested by the tool are not improvements IMO.
libcxx/include/charconv | ||
---|---|---|
253 | I don't find the new one to be more readable. The old one read more naturally as "if *__p is not between '0' and '9'". The new one isn't as clear. | |
libcxx/include/fstream | ||
755–756 | Here too, I don't find the new formulation more readable. | |
libcxx/include/locale | ||
4015–4016 | Same. |
I'm actually quite surprised by that, given that I find the second one you commented on basically unreadable in the current state. Maybe I'm just exceptionally bad at reading negations though.
libcxx/include/charconv | ||
---|---|---|
253 | Here I don't care super much, but I'd read the new version as "if *__p is outside 0 to 9". IMO "outside" is a bit nicer than "not inside", which I'd mentally convert to "outside". | |
libcxx/include/fstream | ||
755–756 | In this case I find the new version much more readable. Instead of "it's not the case that __extbufnext_ is null and __extbufend_ is not equal to __extbufnext_", it reads to me as "__extbufnext_ is not null or __extbufend_ is equal to __extbufnext_". In case of the second one I instantly know that the the iterator is non-null or range is empty; IOW check that we don't dereference a nullptr. To get to that conclusion I actually have to DeMorgan the original version in my head. |
libcxx/include/charconv | ||
---|---|---|
253 | What I like about the previous formulation is that '0' <= *__p && *__p <= '9' immediately reads as 0 <= p <= 9 in my head, I have no need to even think about it. I can't say the same for '0' > *__p || *__p > '9'. In general though -- if we enable this clang-tidy check, what do we do when the tool suggests something that we don't agree with? Can we turn it off for this warning? Tools are nice but I want us to keep in mind that they're only tools meant to help us, the humans, do a better job. If a tool suggests something we don't think is better, we should be happy to turn it off for that instance. | |
libcxx/include/fstream | ||
755–756 | When I read an assertion, I generally read it as assert(!bad-condition-that-shouldnt-happen). In this case, the left hand side made that really clear. With your explanation I do agree that the right hand side also makes sense, but I would then change the code to this instead: if (__extbufend_ != __extbufnext_) { _LIBCPP_ASSERT(__extbufnext_ != NULL, "underflow would be calling memmove on a nullptr"); _VSTD::memmove(__extbuf_, __extbufnext_, __extbufend_ - __extbufnext_); } This makes it clearer that we're specifically trying to guard against this nullptr condition in memmove. WDYT? |
I too am not convinced by this clang-tidy check. I agree it makes the expression simpler, but it seems to make certain cases harder to understand since the "complex" form is more intuitive. I am happy to see we only have a few places where clang-tidy wants to improve our code!
libcxx/include/charconv | ||
---|---|---|
253 | +1 I find this quite confusing. I would write the original or if (*__p < '0' || *__p > '9'). |
Address comments
libcxx/include/charconv | ||
---|---|---|
253 | IMO @Mordante's version is the most readable. @ldionne any objections to that? Re. disabling a check: You can use // NOLINT, // NOLINTNEXTLINE and // NOLINTBEGIN + // NOLINTEND to ignore clang-tidy. Optionally, you can also use //NOLINT*(clang-tidy-check-to-ignore) to disable a specific check (IMO this should be the default). For more details see https://clang.llvm.org/extra/clang-tidy/index.html#suppressing-undesired-diagnostics. | |
libcxx/include/fstream | ||
755–756 | Sounds good. |
For what it's worth, the clang tidy check can be configured to disable transformations based off DeMorgan's law.
Please keep alphabet order.