From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org 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 BAD1421CB2E3D for ; Wed, 3 Jan 2018 08:47:53 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F2E365D68C; Wed, 3 Jan 2018 16:52:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-216.rdu2.redhat.com [10.10.123.216]) by smtp.corp.redhat.com (Postfix) with ESMTP id 30CB65C1AB; Wed, 3 Jan 2018 16:52:53 +0000 (UTC) To: evan.lloyd@arm.com, edk2-devel@lists.01.org Cc: "ard.biesheuvel@linaro.org"@arm.com, "leif.lindholm@linaro.org"@arm.com, "Matteo.Carlini@arm.com"@arm.com, "lersek@redhat.com"@arm.com, "liming.gao@intel.com"@arm.com, "michael.d.kinney@intel.com"@arm.com, "jordan.l.justen@intel.com"@arm.com, "nd@arm.com"@arm.com References: <20180103112248.11880-1-evan.lloyd@arm.com> <20180103112248.11880-3-evan.lloyd@arm.com> From: Laszlo Ersek Message-ID: Date: Wed, 3 Jan 2018 17:52:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180103112248.11880-3-evan.lloyd@arm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 03 Jan 2018 16:52:57 +0000 (UTC) Subject: Re: [edk2-CCodingStandardsSpecification PATCH 2/5] Fix Chapter 2 Typos X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:47:54 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/03/18 12:22, evan.lloyd@arm.com wrote: > From: Evan Lloyd > > 2.1 Accessibility - remove erroneous "as" > 2.1 Confirmation - insert missing full stop > 2.1 Forgiveness - excise superfluous "errors" > 2.1 Standard techniques - remove redundant "be to" > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Evan Lloyd > --- > 2_guiding_principles.md | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/2_guiding_principles.md b/2_guiding_principles.md > index a7759f27dcf71a948b903332c9bc14946e445cd8..5a51225b65dec2159a4fb94481920666c0d042ff 100644 > --- a/2_guiding_principles.md > +++ b/2_guiding_principles.md > @@ -47,7 +47,7 @@ The following is an alphabetical list of software design principles: > **Accessibility** > > This entails designing objects and environments to be usable, with no > -modification, by the greatest number of people as possible, including people > +modification, by the greatest number of people possible, including people > with varying educational and social backgrounds, as well as those with motor or > sensory challenges. > > @@ -68,7 +68,7 @@ shortterm memory, as well as to accommodate its limits. > This is a technique used for critical actions, inputs, or commands. > Confirmations are primarily used to prevent unintended actions. Minimize errors > in critical or irreversible operations with confirmations. If you overuse > -confirmations, expect that they will be ignored Avoid overusing confirmations > +confirmations, expect that they will be ignored. Avoid overusing confirmations > to ensure that they remain unexpected and uncommon; otherwise, they may be > ignored. Use a two-step operation for hardware confirmations and dialogs for > software confirmations. > @@ -97,7 +97,7 @@ about the assumptions you make. > **Forgiveness** > > Design to help users avoid errors and reduce the negative consequences of > -errors any errors made. Recommended methods for achieving design forgiveness > +any errors made. Recommended methods for achieving design forgiveness > include affordances, reversibility of actions, and safety nets. Effectively > designing for forgiveness results in a design needing minimal confirmations, > warnings, and help. > @@ -171,7 +171,7 @@ classes of platforms from embedded systems to massively parallel computers. > > Greater reliance on unique or exotic pieces makes a system harder to > understand, and more intimidating for someone trying to understand it the first > -time. Using standardized, common approaches should be to give the whole system > +time. Using standardized, common approaches should give the whole system > a familiar feeling. This standardization is one of the primary goals of this > document. > > Reviewed-by: Laszlo Ersek