Re: [Qemu-devel] Why do we typedef every struct on QEMU?

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jul 27, 2018 at 02:03:17PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 19, 2018 at 08:42:05AM +0200, Markus Armbruster wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > 
> > > On 17 July 2018 at 20:50, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > Instead, we've repeatedly wasted time on debating which kind of ugly we
> > hate less, and all we can show for our troubles is CODING_STYLE.  Which
> > leaves a whole lot more questions open than it answers, so we can keep
> > enjoying style debates.
> > 
> > That the code shows anything resembling consistency at all is a
> > testament to humanity's yearning for order within a chaotic world.
> 
> Going back to something concrete after this nice philosophical musing:
> 
> The coding style checker (checkpatch.pl) seems like a huge success to
> me.  Without it, achieving consistency is futile.
> 
> checkpatch.pl defines the true coding style of QEMU - the subset that
> can be automatically checked by patchew.  If we want to follow a coding
> style, implementing the rules in checkpatch.pl is important.

Sadly that is not enough and arguably making life worse in some ways.

The core problem is that we never change any existing code to follow
the coding style rules we add. We only require new code to use it. We
have plenty of code that goes years between being touched by a patch,
so we've got countless different coding styles present across the
source tree. What's worse is that when submitting new patches, you have
to merge unrelated style cleanup changes into your functional changes,
just so the patch can pass checkpatch.pl, or go back & clean up enough
of the existing code in a separate patch, so that your patch doesn't
trigger a checkpatch.pl violation :-(

I wish we'd do a blanket cleanup to get the entire codebase passing
checkpatch. Despite the downside that it'd create a conflict point
in the history for people cherry-picking to older branches in the short
term, I think it would be a net win over the long term (3+ years) to
actually have a real coding style that is consistently followed.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|