[LLVMdev] Stricter adherence to coding standards in LLVM?

[Chris Lattner]

On Feb 11, 2011, at 4:17 PM, Talin wrote:

> I notice that there's a lot of code in LLVM core libraries that is wildly inconsistent in formatting. Two particular things come to mind:
> 
> -- Capitalization of method names. The LLVM guidelines say one thing, but a lot of recent code (such as IRBuilder) consistently does the opposite of what the guidelines say. One has to wonder which source of truth is more authoritative - after all, the docs could always be out of date.

IRBuilder is recent, but the naming conventions are even more so.

> -- Whitespace around * and & in variable declarations. I see some files that consistently put the space after, some files put it before, while some files use one convention for parameters, and a different convention for member variables and local variables. Within a single file, the usage is pretty consistent, so you know that the people who wrote the code were really trying to adhere to a standard.

Yes, this is annoying.

> Now, common wisdom for open source projects is that inconsistent legacy formatting is left alone, and new code adheres to whatever style is used in nearby code.
...
>  nip any inconsistencies in the bud as early and aggressively as possible
..
> There is also the problem of backwards compatibility with existing users of the code.

I'm not worried about API stability, this is something we don't guarantee.

The approach I'd like to see is gentle, gradual migration.  As new code is written, it should follow the standards, as existing code is modified, it should be updated to match the standards.  This is what I do when working on the codebase, and would appreciate it if others would as well.  It's best to not conflate coding standards changes in with other semantic changes though.

Eventually, it would be great for someone to make a clang mode to enforce the standards for the project.  If we had that, we could do a post-commit hook or something.

-Chris