Hi David, On Wed, Aug 31, 2016 at 03:14:34PM -0700, David Champion wrote: > * On 31 Aug 2016, Damien Riegel wrote: > > > > Fair enough! There are some guidelines [1] but maybe they could be more > > detailed to have consistent style for new contributions. For instance, > > the expected output of `indent` is not obvious, and it seems to be > > missing some arguments to be closer to what the actual code base looks > > like (ex: most fuctions declarations have their types and names on the > > same line, so -npsl should be added as argument). > > > > [1] https://dev.mutt.org/trac/wiki/CodingStyle > > Indeed, and it doesn't help that there are at least three common > versions of indent (with differing options) in the wild. That needs to > be specified too, or we could just adopt uncrustify or some other tool > that's less ambiguous. I'm not particular until we start bikeshedding. > ;) > > I suggest that we decide upon a style and a target release (1.8? 1.9?)
It's not clear to me who "we" is in this context: people with push access, community, or something else? Anyway style is mostly a matter of taste and in the end we can all adapt to whatever style is chosen. (But please, get rid of the space before parenthesis for functions :). > where that style will be applied to the whole code base. Apply the > style from up top, using rules that are in the repo and no manual > tweaks, between code freeze and release. We can put it in a commit hook > and document installing that hook in the developer notes. There are two main drawbacks here: - Applying new style to the whole code base makes "blame" less useful, because most lines would be changed to a generic restyling commit. - I think it will create unnecessary conflicts for people using patches on top of vanilla mutt. But I can understand people want a clean start, and I personally think the trade-off is worth it. Anyway, first things first, mutt should pick a style and document that. -- Damien
