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.