From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C18F221E14521 for ; Tue, 15 Aug 2017 04:13:42 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 11C15A0C3E; Tue, 15 Aug 2017 11:16:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 11C15A0C3E Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-68.phx2.redhat.com [10.3.116.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id D349C60657; Tue, 15 Aug 2017 11:16:05 +0000 (UTC) To: Leif Lindholm , Jordan Justen Cc: edk2-devel-01 , Michael D Kinney , Ard Biesheuvel References: <20170811164851.9466-1-lersek@redhat.com> <20170811164851.9466-3-lersek@redhat.com> <150248431260.29687.8219608274582743547@jljusten-skl> <20170812101346.6tw7rcs2c7trit2p@bivouac.eciton.net> From: Laszlo Ersek Message-ID: <922996c2-e60a-80ec-6d4a-8b2e5a639c9b@redhat.com> Date: Tue, 15 Aug 2017 13:16:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170812101346.6tw7rcs2c7trit2p@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Aug 2017 11:16:07 +0000 (UTC) Subject: Re: [edk2-CCodingStandardsSpecification PATCH 2/2] Source Files / Spacing / Multi-line func. calls: allow condensed arguments X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 11:13:43 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/12/17 12:13, Leif Lindholm wrote: > On Fri, Aug 11, 2017 at 01:45:12PM -0700, Jordan Justen wrote: >>> +Use this line breaking style especially if it saves a format string or complex >>> +argument from being split, or when commenting on individual arguments. >>> + >>> +##### 5.2.2.4.2 The "condensed arguments" style >>> + >>> +For most function calls and function-like macro invocations, the "one argument >>> +per line" style uses up valuable vertical space without utilizing readily >>> +available horizontal space. Such statements are permitted to condense the >>> +arguments and the closing parenthesis (or parentheses), up to the allowed line >>> +length. The indentation requirements are identical to those of the "one >>> +argument per line" style. >>> + >>> +```c >>> +CopyMem (Destination, Source, SIZE_4KB); >>> + >>> +Status = gBS->AllocatePool (EfiBootServicesData, sizeof (DRIVER_NAME_INSTANCE), >>> + &PrivateData); >> >> I prefer that we just have one style, and just drop the requirement >> that multiline param lists can only have one arg per line. I think it >> is good to have the first param start on the next line in this case. >> >> Status = gBS->AllocatePool ( >> EfiBootServicesData, sizeof (DRIVER_NAME_INSTANCE), >> &PrivateData); > > I like this one better than Laszlo's proposal, since it keeps the > start of each line of parameters in the same column. > >> This compacts things somewhat, but still keeps the parameter list >> aligned horizontally on subsequent lines. >> >> Regarding the closing parens being on a separate line, I think we >> should also remove that as a requirement. > > I would also support that change. > >> I think you might want to break out the multiple params per line and >> closing parens change out to allow for separate discussion. > > That would make sense. > > Laszlo - many thanks to starting this discussion! Thanks all for the feedback. Before I attempt to post version 2, I'd like to see the "preference" wording sorted out (raised by Mike and Jordan). I.e., whether the new style should be merely tolerated (but still frowned upon) or if it should be a first class citizen. (Stating the obvious,) if the new style were accepted into the CCS, personally I would switch to it for all new code written by me (even if the code were for MdePkg or MdeModulePkg), independently of the preference assigned to the new style. I would not require OvmfPkg / ArmVirtPkg contributors to follow my preference -- NB I've been enforcing the one style we now have in the CCS, for the packages I co-maintain, in spite of my dislike for that style -- but I might suggest the alternative style to others if I perceived the vertical space consumption very disturbing. Thanks! Laszlo