Hey folks,
I overeagerly reviewed and submitted a change[1] lately, that set the column limit for our C code to 96. My reasoning was that we already live a "soft" limit of 80 chars and that tools shouldn't complain about every single 8x-chars line (personally, I find this quite annoying during review). What I missed is that people use the limit to format code automatically, resulting in less line breaks, even if they'd make sense for readability.
I don't want to start a discussion about line length here! If we are going to use tools for automatic formatting, we will be limited by the tool's capabilities. So it doesn't make any sense to discuss rules before we know if our tools will allow us to follow them.
So what we should discuss first: if we want to let tools format our code for us. I'll just note some questions/ideas for now. Will try to have an opinion on them later. They are not all mutually exclusive.
Do we want to enforce a single editor / IDE + configuration for coreboot contributions? For instance, Vim is quite configurable and helpful when writing code. This could make all tools for later processing unneces- sary.
Do we want to enforce a single tool, e.g. clang-format, that does the job for us after editing a source file?
The above, even if that implies a new coding style that we might not be used to?
Do we want a combination of such a tool and check-patch? For instance, clang-format has a feature to ignore broken lines. This could then be handled by check-patch, to allow more complex rules.
Do we just want to keep check-patch and let authors / their editors format the code?
Do we want to rely (solely) on reviewers for format checking?
Do we want to encourage reviewers to educate their fellows on code style (for instance, wrt. line length, less indentation levels, shorter, more meaningful identifiers, etc.)?
Nico