From owner-freebsd-chat@FreeBSD.ORG Wed Apr 1 13:35:58 2009 Return-Path: Delivered-To: freebsd-chat@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6164E106564A for ; Wed, 1 Apr 2009 13:35:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 975FB8FC1D for ; Wed, 1 Apr 2009 13:35:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n31DZUjp062213; Wed, 1 Apr 2009 15:35:53 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n31DZT6D062212; Wed, 1 Apr 2009 15:35:29 +0200 (CEST) (envelope-from olli) Date: Wed, 1 Apr 2009 15:35:29 +0200 (CEST) Message-Id: <200904011335.n31DZT6D062212@lurza.secnetix.de> From: Oliver Fromme To: freebsd-chat@FreeBSD.ORG, Polytropon , William Gordon Rutherdale In-Reply-To: <20090401123512.ec165676.freebsd@edvax.de> X-Newsgroups: list.freebsd-questions User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 01 Apr 2009 15:35:53 +0200 (CEST) Cc: Subject: Re: Why?? (prog question) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@FreeBSD.ORG, Polytropon , William Gordon Rutherdale List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:35:58 -0000 Note: I've redirected this to -chat. This thread does *not* belong on the -questions list. Polytropon wrote: > William Gordon Rutherdale wrote: > > You set the standard on a given project. You decide > > whether you are using spaces or tabs. If spaces, you decide how many > > spaces per indent level. You ask the programmers to submit code in that > > format. It doesn't jump around randomly from one line to the next. > > Okay, now I understand what you mean. "Consistency" refers to > the usage of spacing / tabbing for a given project that is > adopted by several programmers. Yes, I agree with that: It's > a very bad idea to have many different styles within the same > project. Of course. That's why the FreeBSD project has the style(9) manual page. Newly written code has to obey it, otherwise it will not go into the repository. Of course there are certain exceptions, e.g. for "contrib" code. > > You are trying to make it sound like a big problem, but it isn't. > > When I need to read / work with other's code, it's can develop > into problems. Natural habits like hitting the tab key are > very hard to change several times, for each project a different > rule. There's no problem with hitting the Tab key. Your editor takes care of the actual behaviour. For example, I have configured my editor to use literal tabs for Makefiles and shell scripts, and display them with 8 positions apart, but for Python programs display them only with 4 positions apart. For C source code, the behaviour depends on the project (directory). For the FreeBSD project, tabs with size 8 are used (according to style(9)), but for some other projects, spaces are inserted (4 or 8). For most other types of files, the key inserts various amounts of space characters. In all of those cases, I simply press the key to indent, and the key to dedent. There is no need to change habits. The editor takes care of it. I assume that every modern editor can be configured that way. > But the ability to read it is not the only important thing. It's > how you use it, because programmers usually do more than just > reading, they continue developing. The tab approach allows them > to have their individual viewing options without needing to > reformat the code. No, that won't work. In practice you will either have to adopt the original indentation style, or reformat the code. Just changing the tab size in your editor will break many things. Here's an example. I'll use /usr/include/stdio.h for this example because it's installed almost everywhere, even if your don't have /usr/src. $ less +100 /usr/include/stdio.h That command should show you the typedef declaration of struct __sFILE, which is about 30 lines. Note how the types, names and comment columns line up neatly. Now view the same with tab size 4: $ less -x4 +100 /usr/include/stdio.h See the difference? It's a complete mess. > But maybe if I pass ^TD8 code to you, you would want to > work with it in ^TD4. No, I wouldn't. If I did only minor changes, I would simply stick to the existing style of the file. And if I did substantial changes, I would probably reformat the whole file -- note that this does *not* only change the indentation style, but much more. Indentation is only a part of the style, and probably not even the most important part. > > > + you need more keypressing to get through the indentation with > > > the spaces, one keypress per space, while you only need one > > > keypress per tab (which equals one indentation level), > > > > Not true. You set up your editor settings to automatically do this for > > you. Most editors have this capability. > > Not all editors have this ability. Tell me a common editor that doesn't have that ability. And no, ee(1) doesn't count. I'm not aware of a FreeBSD developer who uses ee(1) for serious work. > Not every programmer uses vim, emacs or Eclipse. Some really > like the "old fashioned" ways like joe. Oh, good thing you mention joe. I'm typing this reply in joe right now. I use joe for almost 20 years, and it *does* support all of the features mentioned above. Best regards Oliver PS: Personally I think that the tab character (ASCII 9) should die. It is a vestige of the IT middle ages, it has no right to exist anymore today, and it only causes problems. The very existence of this thread proves this point. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980