From nobody Tue Dec 24 02:27:58 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1514978591066255.58794109275573; Wed, 3 Jan 2018 03:23:11 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 758D3222A54F6; Wed, 3 Jan 2018 03:18:00 -0800 (PST) Received: from cam-smtp0.cambridge.arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 151B6222A54E9 for ; Wed, 3 Jan 2018 03:17:56 -0800 (PST) Received: from E111747.Emea.Arm.com (e111747.emea.arm.com [10.1.27.84]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with ESMTP id w03BMrgl021422; Wed, 3 Jan 2018 11:22:54 GMT X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=217.140.96.140; helo=cam-smtp0.cambridge.arm.com; envelope-from=evan.lloyd@arm.com; receiver=edk2-devel@lists.01.org From: evan.lloyd@arm.com To: edk2-devel@lists.01.org Date: Wed, 3 Jan 2018 11:22:45 +0000 Message-Id: <20180103112248.11880-3-evan.lloyd@arm.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180103112248.11880-1-evan.lloyd@arm.com> References: <20180103112248.11880-1-evan.lloyd@arm.com> Subject: [edk2] [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: , Cc: "Matteo.Carlini@arm.com"@arm.com, "nd@arm.com"@arm.com, "ard.biesheuvel@linaro.org"@arm.com, "lersek@redhat.com"@arm.com, "jordan.l.justen@intel.com"@arm.com, "liming.gao@intel.com"@arm.com, "leif.lindholm@linaro.org"@arm.com, "michael.d.kinney@intel.com"@arm.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: Laszlo Ersek --- 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..5a51225b65dec2159a4fb944819= 20666c0d042ff 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** =20 This entails designing objects and environments to be usable, with no -modification, by the greatest number of people as possible, including peop= le +modification, by the greatest number of people possible, including people with varying educational and social backgrounds, as well as those with mot= or or sensory challenges. =20 @@ -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 e= rrors in critical or irreversible operations with confirmations. If you overuse -confirmations, expect that they will be ignored Avoid overusing confirmati= ons +confirmations, expect that they will be ignored. Avoid overusing confirmat= ions to ensure that they remain unexpected and uncommon; otherwise, they may be ignored. Use a two-step operation for hardware confirmations and dialogs f= or software confirmations. @@ -97,7 +97,7 @@ about the assumptions you make. **Forgiveness** =20 Design to help users avoid errors and reduce the negative consequences of -errors any errors made. Recommended methods for achieving design forgivene= ss +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 confirmation= s, warnings, and help. @@ -171,7 +171,7 @@ classes of platforms from embedded systems to massively= parallel computers. =20 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 sy= stem +time. Using standardized, common approaches should give the whole system a familiar feeling. This standardization is one of the primary goals of th= is document. =20 --=20 Guid("CE165669-3EF3-493F-B85D-6190EE5B9759") _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel