clang

ysicalStartOfLine) { [...] if ((*CurPtr == ' ') || (*CurPtr == '\t')) { ++CurPtr; while ((*CurPtr == ' ') || (*CurPtr == '\t')) ++CurPtr; [...] } [...] } There are a number of places in the world where you might find that text parsing is performance-critical. Note that in the rest of the code base, Clang uses really quite standard and boring std::string to represent strings. You don't have to use sentinels everywhere, but it's a trick to keep up your sleeve for the cases where it makes a difference. And of course, you keep the parts of your code with sentinels self-contained because it can be hard to figure out whether the code is correct without a close reading.

rom scratch, which is a much larger undertaking than C99 plus a few GNU extensions. [1]: https://github.com/llvm-mirror/clang/blob/fb2a26cc2e40e007f1... [2]: https://github.com/llvm-mirror/clang/blob/master/bindings/py...

family/c-l... 3. https://github.com/llvm-mirror/clang/blob/master/lib/Lex/Lex... I always find it helpful to look at one problem solved different ways. Of course it's not always apples-to-apples but it's as close as you're going to get. Out of these three codebases, there is probably one you'd feel more comfortable working with. I merely threw mine in there because I wrote it as an exercise on what it'd be like to have a hand-written lexer read more like a story. It has a focused interface, most functions are descriptively named and operate at a single-level of abstraction, and it's easy to intuit what a C lexer does even if you're not familiar with what they're supposed to do. I'm sure it'd be easy for most people to jump into my code and contribute. Just like with LLVM's lexer. LLVM is far easier to jump in and contribute to than GCC. However, and this is just an example that immediately jumps out to me since we're talking about it... doesn't it make sense to have this comment and code abstracted out into a respectively descriptive function instead: void Lexer::InitLexer(const char *BufStart, const char *BufPtr, const char *BufEnd) { // ... // Check whether we have a BOM in the beginning of the buffer. If yes - act // accordingly. Right now we support only UTF-8 with and without BOM, so, just // skip the UTF-8 BOM if it's present. if (BufferStart == BufferPtr) { // Determine the size of the BOM. StringRef Buf(BufferStart, BufferEnd - BufferStart); size_t BOMLength = llvm::StringSwitch<size_t>(Buf) .StartsWith("\xEF\xBB\xBF", 3) // UTF-8 BOM .Default(0); // Skip the BOM. BufferPtr += BOMLength; } // ... } I mean think about it... we're concerned with initializing the lexer, why am I being bothered with this string manipulation minutia to determine whether there's a BOM or not? That could be extracted into a properly named function, the comment eliminated, and then I could trust that that function does exactly what it says on the tin can. And there's plenty more places where this line of reasoning applies too. Jekyll (https://github.com/jekyll/jekyll) is another example of a codebase that's very easy to read, work with, modify, etc. It's very well-written. It follows Clean Code like principles where it makes sense. On the other side of the coin we have Kubernetes (https://github.com/kubernetes/kubernetes) which looks ready to collapse under its own complexity. It's supremely difficult to read and understand what's going on not because of the essential complexity of the problem but because of all the incidental complexity added by the code structure. I could spend forever citing examples on both sides because I've spent a great deal of time thinking about this and talking with other seasoned developers. If you (or anyone really) could, please offer up concrete examples grounded in real production code. I'm always interested to see more examples. Specifically examples blind Clean Code dogmatism applied in the wild.

c version moved the flakier uninitialized warnings to a new -Wmaybe-uninitialized flag. In my experience with Firefox, -Wmaybe-uninitialized warnings are false positives about 90% of the time. On the other hand, clang has a -Wsometimes-uninitialized which is reliable. For bool++, clang has -Wdeprecated-increment-bool. btw, clang does not document its warning flags, but some resources I've used are the http://fuckingclangwarnings.com/ reference, searching through clang's source code at https://github.com/llvm-mirror/clang/blob/master/include/cla..., and clang's -Weverything flag (which truly is everything, including contradictory warnings).