From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50401 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oke0d-0004cd-S9 for qemu-devel@nongnu.org; Sun, 15 Aug 2010 10:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oke0c-00061F-NL for qemu-devel@nongnu.org; Sun, 15 Aug 2010 10:16:23 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:65166) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oke0c-000617-IE for qemu-devel@nongnu.org; Sun, 15 Aug 2010 10:16:22 -0400 Received: by fxm7 with SMTP id 7so2719375fxm.4 for ; Sun, 15 Aug 2010 07:16:22 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4C67F3F0.3060504@redhat.com> Date: Sun, 15 Aug 2010 10:04:32 -0400 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/5] CODING_STYLE amendments List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Blue Swirl , qemu-devel On 08/12/2010 02:56 PM, malc wrote: > On Thu, 12 Aug 2010, Blue Swirl wrote: > >> Add a few rules, based loosely on libvirt HACKING. >> >> Blue Swirl (5): >> CODING_STYLE: add preprocessor rules >> CODING_STYLE: add C type rules >> CODING_STYLE: add memory management rules >> CODING_STYLE: add string management rules >> CODING_STYLE: add rules for printf-like functions >> >> CODING_STYLE | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 111 insertions(+), 0 deletions(-) > > While intentions of this are good, i believe this goes too far, i doubt > that the proposed additions are enforcable and have no doubts that they > will be widely ignored and at the same time provide more grounds for > whining. Furthermore the existing code doesn't follow them, going out on > a limb, it's more likely that one would look around the code he/she > modifies and base his/her modifications on the surrounding code than to > follow the style that conflicts with it. I think this doesn't matter. The rules Blue Swirl suggested (with a couple of exception regarding C types) are mostly dictated by common sense and would likely be spotted anyway during review. In fact, unlike the braces some of them do provide slight advantages in terms of code quality and avoiding hidden bugs (e.g. size_t vs. int, off_t vs. long). Even without a "guardian" (whose time would be better spent continuing on his QMPification project), I suggest putting in at least patches 1/3/4/5 now. Paolo