Quoting my test case: #include "a.h" '#include "B.h" '#include "c.h" That thing currently fails. The fix is straightforward, patch goes below.
Created attachment 33284 [details] Case-insensitive comparison of include file order for cpplint
Comment on attachment 33284 [details] Case-insensitive comparison of include file order for cpplint The order is supposed to be case-sensitive, as if done by the command line "sort" tool. Did someone say it should be case-insensitive?
Comment on attachment 33284 [details] Case-insensitive comparison of include file order for cpplint Setting to review- for now. I believe the sort is supposed to be case sensitive, but if there is consensus otherwise, then this is a good change to make.
Oops. I committed it already. Should I back out until we find consensus?
(In reply to comment #4) > Oops. I committed it already. Should I back out until we find consensus? Yes, I think so. I'm almost certain our standard was case-sensitive as done by the "sort" tool, and I believe it would require discussion to change that.
Then I'm probably adding a test case to clarify that way of working, right?
Reverted with r46235. Sorry guys. It just doesn't seem very intuitive to me to sort alphabetically with case-sensitivity. But if thems the rules, thems the rules.
sort -f? All in all the concept of sorting headers alphabetically as a rule seems like a scary and arbitrary decision, though I'm really not interested in debating it.
Why do we sort at all? One reason is to make it less likely we will end up with duplicate includes. Another is to ensure we don't get a variety of different "logical" sorting orders invented by different well-meaning programmers in different source files. Case-sensitive vs. case-insensitive is entirely arbitrary, and we chose case-sensitive long ago. I'd be open to considering a change.