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 D7A6E21CE7490 for ; Fri, 4 Aug 2017 13:23:00 -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 D43EDC056791; Fri, 4 Aug 2017 20:25:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D43EDC056791 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-151.phx2.redhat.com [10.3.116.151]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB12E5C6ED; Fri, 4 Aug 2017 20:25:10 +0000 (UTC) To: Jordan Justen , Brijesh Singh , edk2-devel@lists.01.org Cc: Tom Lendacky , Ard Biesheuvel References: <1501776600-16369-1-git-send-email-brijesh.singh@amd.com> <1501776600-16369-2-git-send-email-brijesh.singh@amd.com> <2517ecce-c92c-b85c-39a7-f454048e6b3d@redhat.com> <2b7e7cfb-0006-9dc2-951f-2d1f7d1a3214@redhat.com> <150186651004.27627.8056916076752739657@jljusten-skl> From: Laszlo Ersek Message-ID: Date: Fri, 4 Aug 2017 22:25:09 +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: <150186651004.27627.8056916076752739657@jljusten-skl> 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.32]); Fri, 04 Aug 2017 20:25:13 +0000 (UTC) Subject: Re: [PATCH v2 1/1] OvmfPkg : QemuFwCfgLib: Use BusMasterCommandBuffer to map FW_CFG_DMA_ACCESS 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: Fri, 04 Aug 2017 20:23:01 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/04/17 19:08, Jordan Justen wrote: > On 2017-08-03 15:27:46, Laszlo Ersek wrote: >> On 08/04/17 00:07, Brijesh Singh wrote: >>> Hi Laszlo, >>> >>> Thanks for the detail review, I will soon send v3 with all your feedback >>> addressed. I must admit that I have constant struggle with formating issues >>> in EDKII contributions. While browsing the code, several packages have >>> code and comment exceeding 79 char. But looking at your previous feedbacks >>> somehow I was under assumption that comments should be <= 79 chars but code >>> can exceed 79 char limit. I think my understanding was wrong. I will update >>> my vi setting to warn me when I exceed 79 char limit. >> >> In the coding style, you will find: >> >> https://edk2-docs.gitbooks.io/edk-ii-c-coding-standards-specification/content/5_source_files/#51-general-rules >> >> ---------- >> 5 Source Files >> 5.1 General Rules >> 5.1.1 Lines shall be 120 columns, or less >> >> Preferably, limit line lengths to 80 columns or less. When this doesn't >> leave sufficient space for a good postfix style comment, extend the line >> to a total of 120 columns. Having some level of uniformity in the >> expected width of the source is useful for viewing and printing the code. > > I personally don't like this wording. It basically says, 'we prefer > 80, but if that is too difficult, then 120 is ok'. The only case I've > ever seen of where code wouldn't fit reasonably in 80 columns, someone > was essentially putting a spreadsheet into code. (This is not exactly > a good case to build a code style around.) > >> ---------- >> >> I stick with 79 chars because they don't wrap in any kind of window >> sized to 80 columns. (Some terminal emulators / pager programs insert >> blank lines or wrap unexpectedly when a line is exactly 80 columns.) >> And, I like to size my windows to 80 columns because I use only one >> monitor (I dislike using more than one) and with 80 cols/window I can >> fit two windows side by side conveniently. > > History (punch cards) and personal workflows (fitting multiple > terminals) are often cited as reasons for the 'eighty column rule', > but more fundamentally, I prefer this argument: > > https://softwareengineering.stackexchange.com/a/222998 > > Essentially, there's a reason newspapers have columns. It is not easy > for humans to read very long lines of text. I appreciate that the stackoverflow comment also mentions "If lines are too short, text becomes hard to read because you must constantly jump from one line to the next while reading." > > I have another reason why going beyond 80 is not a good idea for code > that doesn't apply to normal reading. If you need ~120 columns visible > to view some lines, then most lines will end up having a lot of wasted > horizontal whitespace because they can commonly fit into 80 columns. One reason I dislike the "all arguments on separate lines" rule is just this -- it wastes perfectly good horizontal space, and eats up precious vertical space. We have a patch submission process for our documents now, but I don't think maintainers of other Pkgs would bother with following and enforcing a stricter 80 columns rule, even if we got it codified. :/ Thanks Laszlo