From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127612 invoked by alias); 5 Dec 2019 18:54:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 127587 invoked by uid 89); 5 Dec 2019 18:54:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=estate, fan, symptom, norm X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2019 18:54:07 +0000 Received: by mail-ot1-f65.google.com with SMTP id 66so3531125otd.9; Thu, 05 Dec 2019 10:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QlRkq5AikP2chRj7Zi+bTyR01vjBNTLFHMyFIfN1SF8=; b=oAwZVdvvwJDxhVwD1aN3vyoAxFMfn997gcjm18DPSzPtE8wnfUIbJK1PQsO1IqG+lV yukxrJltGchPrYIaNbGKzlkbVxro9Uj70FRTRfs91QKzzOxEFStP+GMzOkH37v+YuWyP aN/aj0fzujIMd/qWp3hzk2/7C1bUgAD1GDpzNyFheh+/QUp7/Gty0gjkWv+omGcm6LRx D4x21JCRLzqDtc8NNQYTufVNgoGu8VAaIV5AIJRVJOnaZ6lCVgxOsqF6enqotVXrLXOH EnIVboH1k/D8lUQ50ZS0BjYGa0N0ujt/l5tvydjQS7nqxkqTFlSDBN5hMSFI2hgAgTIZ Tn7g== Return-Path: Received: from [192.168.0.41] (75-166-111-174.hlrn.qwest.net. [75.166.111.174]) by smtp.gmail.com with ESMTPSA id w201sm1593593oif.29.2019.12.05.10.54.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2019 10:54:05 -0800 (PST) Subject: Re: [RFC] Characters per line: from punch card (80) to line printer (132) To: Thomas Schwinge , gcc@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, Jakub Jelinek , Tobias Burnus , Michael Meissner References: <8be82276-81b1-817c-fcd2-51f24f5fe2d2@codesourcery.com> <20191205151515.GS10088@tucnak> <87lfrq6ahm.fsf@euler.schwinge.homeip.net> From: Martin Sebor Message-ID: Date: Thu, 05 Dec 2019 18:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87lfrq6ahm.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00082.txt.bz2 On 12/5/19 8:46 AM, Thomas Schwinge wrote: > Hi! > > ;-P Jakub, thanks for furnishing me a fit occasion here: > > On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote: >> [...] much more indented though, but you could >> use a temporary, like: >> tree nullarg = null_pointer_node; > > I object to cluttering the code by introducing temporary variables/names > just for the sake of a few characters of screen width. Even if located > close lexically, when reading the following code you still have to trace > back from the 'nullarg' usage to its 'null_pointer_node' definition in > order to figure out what a 'nullarg' might be: > >> if (present) >> ptr >> = gfc_build_conditional_assign_expr (block, present, >> ptr, nullarg); The snippet of code above looks like it might be the symptom of another common problem: deeply nested conditionals, case statements, or loops in very large functions. Those usually make it much harder to follow code than local variables or expressions that are broken up to fit the width limit. Shorter functions typically also means fewer local variables. One thing I find improves readability in functions with many local variables is declaring const those that don't change after initialization. That also enforces the initialization- on-declaration coding style, and can result in more efficient code. Another solution that might help in this context is default function arguments: if the last argument may be null, making it the default in the function declaration avoids having to pass it explicitly. > >> Another option would be shorten the name of the function, say >> s/conditional/cond/. As long as it doesn't compromise readability this sounds like a good suggestion for a change to the function above. _cond_ is no less clear or descriptive than _conditional_, similarly to _expr vs _expression. > > Likewise I object to "crippling" identifier names like that just for the > sake of a few characters of screen width. (Here of course, "cond", or > the existing "expr" might be fine abbreviations, but my point is about > the general case.) > >> There were some discussions about lifting the 80 column restriction and bump >> it to something like +-130, but nothing happened yet. > > Indeed. :-) > > In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner > stated that even he is not using a 80 x 24 terminal anymore, and that > should tell us something. ;-) > > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). I'm not a fan of rigid rules, especially those that are subject to personal style preferences. At the same time I wouldn't like to see lines become as long as this as the norm. As others, I have windows om my desktop arranged in a way to maximize screen real estate: three columns of editor/debugger and a couple of terminals on of top of the other. They only fit because they're all 80 characters wide. But more important: > deep > indentation often is a sign that code should be split out into a separate > function, for example. Exactly. Martin My point is just to avoid things like the two > examples cited above. > > Also, I'm not proposing any mass-reformatting of the existing code, or > re-writing all "expr" into "expression". > > Tasks: > > - Discussion. > - Get agreement/make a decision (by means still to be determined). > - Put suitable Emacs/Vim configuration files into the source tree? > - Update coding style guidelines. > > > Grüße > Thomas >