From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9249 invoked from network); 5 Mar 2021 00:15:55 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2021 00:15:55 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A07ED9CA6B; Fri, 5 Mar 2021 10:15:51 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 45ECC9CA68; Fri, 5 Mar 2021 10:15:21 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id D58C39CA68; Fri, 5 Mar 2021 10:15:18 +1000 (AEST) Received: from fourwinds.com (fourwinds.com [63.64.179.162]) by minnie.tuhs.org (Postfix) with ESMTPS id 1332A9CA67 for ; Fri, 5 Mar 2021 10:15:18 +1000 (AEST) Received: from darkstar.fourwinds.com (localhost [127.0.0.1]) by fourwinds.com (8.15.2/8.15.2) with ESMTPS id 1250FHfL053762 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Thu, 4 Mar 2021 16:15:17 -0800 Received: from darkstar.fourwinds.com (jon@localhost) by darkstar.fourwinds.com (8.15.2/8.15.2/Submit) with ESMTP id 1250FG1d053755 for ; Thu, 4 Mar 2021 16:15:17 -0800 Message-Id: <202103050015.1250FG1d053755@darkstar.fourwinds.com> From: Jon Steinhart To: TUHS main list In-reply-to: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Comments: In-reply-to Andy Kosela message dated "Thu, 04 Mar 2021 23:08:53 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53749.1614903316.1@darkstar.fourwinds.com> Date: Thu, 04 Mar 2021 16:15:16 -0800 X-JON-SPAM: local delivery Subject: Re: [TUHS] tabs vs spaces - entab, detab X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Andy Kosela writes: > I am still computing in full screen text mode on CRT monitors, so it's > 80 columns and 8 character tab as indentation for me. It is a golden > standard. > > >From Linux kernel coding style doc: > "Tabs are 8 characters, and thus indentations are also 8 characters. > There are heretic movements that try to make indentations 4 (or even > 2!) characters deep, and that is akin to trying to define the value of > PI to be 3." > > --Andy Well, I suppose that I have to weigh in here before this discussion gets shut down. First of all, it's a shame that there isn't a nice global way to set system tab stops. I have a lot of aliases that pipe through "expand -t 4". Second, while I agree with about 90% of the linux kernel coding style the indent and line length parts are in the other 10%. And from looking at kernel code, while many may agree with the style doc they don't actually follow it so I'm not sure what agreement means. I always thought that the 80 character line length limit (now an amazing 100) was silly; nobody was using VT-100s by the time that linux was developed. Most developers were born after the last one was relegated to a museum somewhere. In that timeframe I had changed to using 132 column; I would have gone to 160 but not everybody that I worked with thought that it was worth whatever it took to have a great monitor. I have UHD on both my desktop and laptop which allows a pair of nicely readable 132 column windows with room left over. No longer much of a cost barrier. The big problem that I have with the linux style is that in addition to the tab stop and line length restrictions, there is the weird belief that one is doing something wrong if more than three levels of indent are needed. From what I have seen, this is followed by unnecessarily breaking up functions combined with zillions of macros and static inline functions in header files to give the appearance of only three levels of indent. Bottom line to me is that it makes the code unreadable, and if I have to choose an ideology it's making the code easy to read for someone who didn't write it, not some slavish adherence to a rule that doesn't make a lot of sense to me. I think that line breaks hurt readability as they make it harder to mentally process the block structure of code in pre-attentive mode. I used to have 8 character tab stops and short (traditional one character) variable names; now I've moved to 4 character tab stops and more readable variable names. When I do need to break a long line, I indent the continuation line(s) one character from the starting line to preserve the block structure appearance as much as possible. No additional indent makes it hard to distinguish separate statements, two character indent makes it hard to tell which level the line belongs to since it's halfway between two levels. I do use tabs, not spaces. Main reason, going back decades, is that I can find a statement by searching for "^Ifor" which is distinct from any other use of for. For the same reason, I put function definitions in column 1 with the type on the line above, so that I can easily search for "^foo" which is distinct from any invocations. Anyway, whether or not you agree with this it works for me; my goal is to make my code comprehensible by people who aren't as smart as I am because I want to move on, not maintain stuff. Jon