From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Loe3c-0007yh-0L for qemu-devel@nongnu.org; Tue, 31 Mar 2009 09:31:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Loe3X-0007xD-CG for qemu-devel@nongnu.org; Tue, 31 Mar 2009 09:31:11 -0400 Received: from [199.232.76.173] (port=39349 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Loe3W-0007x5-Sr for qemu-devel@nongnu.org; Tue, 31 Mar 2009 09:31:06 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59061) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Loe3W-0004xg-Dy for qemu-devel@nongnu.org; Tue, 31 Mar 2009 09:31:06 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2VDV588021972 for ; Tue, 31 Mar 2009 09:31:05 -0400 Message-ID: <49D21B17.2040906@redhat.com> Date: Tue, 31 Mar 2009 16:31:03 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Document Qemu coding style References: <49D12392.6040107@redhat.com> <20090330214321.GP3795@csclub.uwaterloo.ca> <20090330.161514.117919654.imp@bsdimp.com> <20090330233853.GT3795@csclub.uwaterloo.ca> <761ea48b0903302259p31b13c76s4c44396b8e33166b@mail.gmail.com> <60cad3f0903310558j554d6906q6f1244fd8a7449aa@mail.gmail.com> In-Reply-To: <60cad3f0903310558j554d6906q6f1244fd8a7449aa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org David Turner wrote: > Very frankly, I don't think that a coding style, even strictly > applied, is going to make the QEMU code > easier to understand. > The coding style is not intended to make the code clearer, just to make it more uniform. > The real barriers to understanding are the lack of structure in the > code, liberal use of global macros > scattered randomly in the source code, exceedingly liberally named > functions, and sometimes obscure > implementation of simple concepts (*cough* CharDriverState), cramming > totally unrelated stuff in single > largish source files (vl.c for the win !), and a blatant lack of > documentation comments for a lot of subtle > stuff in there to explain the magic. This is the QEMU coding style. Seriously, what you say is largely true, but the way to fix it is to sent patches or to review posted patches. Nothing else will make a difference. -- error compiling committee.c: too many arguments to function