Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 37FAC9248 for ; Mon, 27 Feb 2012 21:47:20 +0000 (UTC) Received: (qmail 24666 invoked by uid 500); 27 Feb 2012 21:47:19 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 24625 invoked by uid 500); 27 Feb 2012 21:47:19 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 24616 invoked by uid 99); 27 Feb 2012 21:47:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2012 21:47:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of olegsivokon@gmail.com designates 209.85.210.175 as permitted sender) Received: from [209.85.210.175] (HELO mail-iy0-f175.google.com) (209.85.210.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2012 21:47:11 +0000 Received: by iaby12 with SMTP id y12so7215933iab.6 for ; Mon, 27 Feb 2012 13:46:31 -0800 (PST) Received-SPF: pass (google.com: domain of olegsivokon@gmail.com designates 10.42.159.135 as permitted sender) client-ip=10.42.159.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of olegsivokon@gmail.com designates 10.42.159.135 as permitted sender) smtp.mail=olegsivokon@gmail.com; dkim=pass header.i=olegsivokon@gmail.com Received: from mr.google.com ([10.42.159.135]) by 10.42.159.135 with SMTP id l7mr16351750icx.33.1330379191874 (num_hops = 1); Mon, 27 Feb 2012 13:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PeHmD1KuKIiurKDORIWktsEC0ajnsQlbYRuL1xQg0ik=; b=E9Bu062t9bk5CsnVx21L1FRlLoWShbbyifFzupQ1Q+wz5AOdMd7pKhhC/7NcMjhxya qiJjhxj5c5exjtjyZiPAyJzBIvh4hi6LJdYkNQ0usYgb8swDv8/QPqbRH1Yl+97lG5vC vvhkwqFBQ+Rgm8bM7hCwY6Dw4rYcspoUya2IM= MIME-Version: 1.0 Received: by 10.42.159.135 with SMTP id l7mr13190399icx.33.1330379191813; Mon, 27 Feb 2012 13:46:31 -0800 (PST) Received: by 10.42.224.132 with HTTP; Mon, 27 Feb 2012 13:46:31 -0800 (PST) In-Reply-To: References: <149F8129B58B2D418508E63117D9C5419B0DBE7F2E@nambx05.corp.adobe.com> Date: Mon, 27 Feb 2012 23:46:31 +0200 Message-ID: Subject: Re: Code formatting for patch submissions From: Left Right To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=90e6ba6e87422507dc04b9f90b7f X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba6e87422507dc04b9f90b7f Content-Type: text/plain; charset=ISO-8859-1 A bore in me says: 80 characters limitation isn't related to CRT technology, it comes from terminals, which inherited this limitation from analogue devices - typewriters. In the olden days, if you submitted the manuscript to print, the A4 contained exactly 72 characters in a line typed on typewriter. It could be even an ISO standard or something. This, including the width of the margins would make up for 80 characters. Nowadays some find this limitation out of date, however, it is rooted in a research into Roman-German family of languages and the optimal number of characters of an optimal size the human would be likely to digest. This has been altered many times, and the civilization plagued by computer-generated texts has lost the battle between the ugly and beautiful :) And, if you are on a Mac, then the line 100 characters long of the same font, same size looks _entirely_ different than it looks on PC. Now add to that that some people use different fonts to render the code, and some particularly anathemas use variable-width fonts to render the code (Bjorne Straustrup for instance)! There are still things that are limiting the code width to 80 characters: 1. Book publishing. If you want your code to retain it's original view in the book, trust me, 80 characters, and not a single one more! 2. Sending code via e-mail. E-mail systems were invented in between Fidonet become extinct and just couple million years before the dinosaurs become extinct. They still wrap text at precisely 80 characters, so if you want to send your code intact, 80 characters and don't you dare to add more. 3. Mergetools and people that use them. Them people who use them like to see 3 screenfulls of code at one time [theirs] [merged] [mine]. Having to scroll the screens yields a lot of yielding at those unaware of 80 characters per line limitation. I'm not arguing the 100 characters limitation, it's only that I will probably, instinctively wrap lines before they are that long. I would, however, be happy if the curly brackets following package declaration were allowed to not to create an additional indent, because it creates 12 spaces before you started to write _any_ code at all (which, for example, according to Linux code guidelines is already too late for you to write any code). :) I saw that this was randomly done in some files in the SDK. I'd be in favor that would be made into a rule. Best. wvxvw --90e6ba6e87422507dc04b9f90b7f--