[neomutt-devel] mutt's coding style
Kevin J. McCarthy
kevin at 8t8.us
Wed Nov 2 23:34:06 CET 2016
On Wed, Nov 02, 2016 at 08:40:50PM +0100, toogley at mailbox.org wrote:
> I'm just curious, but what do you think about mutt's coding style? I
> don't mean the theory like its written on
> https://dev.mutt.org/trac/wiki/CodingStyle, rather the practical
> If i clone the official mutt source code and run "indent -nce -bls
> --braces-after-if-line --brace-indent0 --case-indentation2
> --indent-level2 *.c" on it, I see about 81123 lines changing in 114
> different files. So i don't think we can say that the mutt coding
> style is very strictly followed. :D
There are several versions of indent out there, but for GNU indent I'm
% hg diff | grep '^\-' | wc -l
However, this number blows the problem out of proportion. Quite a bit
is not really coding style violations: it's strict 80-column wrapping,
re-indenting comments, and fiddly spacing changes. There is also a fair
amount of trailing space issues.
This isn't to say there aren't problems (the gpgme.c code probably being
the worst), but it's not as horrific as has been suggested in the past
(and this discussion has come up several times on mutt-dev).
> What do you think is the reason for that? Are there any things which
> block following the coding style in a strict way?
It's a 20+ year old code base. I believe the indent invocation on that
wiki page was to give a guideline. But given the variation in indent
versions and relatively small development community, strict enforcement
wasn't (and still isn't) the highest priority.
> Just out of curiosity: if we use e.g. clang-format and the linux
> kernel coding style (automatically), would you change it too? Do you
> have any motivation regarding changing the mutt's coding style?
I generally like the mutt coding style. The changes I *personally*
would like to see would be the function invocation style (removing the
space before the parens), and using spaces for indentation (sorry, I'm
firmly in the "tabs must die" camp).
As Rich discovered, the community is not too happy with an external
contributor driving this or posting a ginormous patch.
However, this has been discussed again recently, and is on my todo list
for 1.8 or 1.9. I may start looking at this in December or January.
I haven't looked at clang-format, and am not familiar with the
differences between the linux style and mutt style. Suggestions about a
clang-format starting point *would* be welcome. If the tool works well,
I would have no problem using that as an enforced standard.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the neomutt-devel