[GRASS-dev] Tabs and spaces in C code

Hi,

as you know, in C code we have mixed tabs and spaces. When I was explaining somebody why the files must be formated is such a strange way (either using script, in editor, or manually), I realized that I really want to change it.

What about formatting the new files in some more standard way? For example, using only spaces for all levels of indentation.

In other words, if there is some rule there should be some reasoning behind it. Four spaces for first level and one tab for second level does not make any sense to me. If old files cannot be changed, let’s at least not introduce bad practice to new files.

What do you think?

Vaclav

http://trac.osgeo.org/grass/ticket/1663
http://trac.osgeo.org/grass/ticket/1832
http://trac.osgeo.org/grass/browser/grass-addons/tools/module_svn_propset.sh
http://trac.osgeo.org/grass/export/61706/grass-addons/tools/module_svn_propset.sh

PS: Doing same for Python (mixing tabs and spaces) is considered as very bad practice and there is even command line switch with will cause Python to fail if you are doing this. Requiring to mix tabs and spaces for C and not to mix for Python might lead to not keeping any rules because they are contradicting each other.

On Wed, Aug 20, 2014 at 4:08 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

http://trac.osgeo.org/grass/browser/grass-addons/tools/module_svn_propset.sh

http://trac.osgeo.org/grass/export/61706/grass-addons/tools/module_svn_propset.sh

Of course I meant this script which creates exactly the strange format I'm
talking about. There is even no comment or waring discussing the quite
unexpected behavior of a script which should create nice standardized code.

http://trac.osgeo.org/grass/browser/grass/trunk/tools/grass_indent.sh
http://trac.osgeo.org/grass/export/61706/grass/trunk/tools/grass_indent.sh

On Wed, Aug 20, 2014 at 10:21 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Of course I meant this script which creates exactly the strange format I'm
talking about. There is even no comment or waring discussing the quite
unexpected behavior of a script which should create nice standardized code.

The discussion was in 2008, for some pointers, see

http://lists.osgeo.org/pipermail/grass-dev/2008-April/037622.html
...

Applied:
http://lists.osgeo.org/pipermail/grass-dev/2008-August/039200.html

No problem to discuss again of course.

Markus

On Wed, Aug 20, 2014 at 5:14 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Aug 20, 2014 at 10:21 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
> Of course I meant this script which creates exactly the strange format
I'm
> talking about. There is even no comment or waring discussing the quite
> unexpected behavior of a script which should create nice standardized
code.

The discussion was in 2008, for some pointers, see

http://lists.osgeo.org/pipermail/grass-dev/2008-April/037622.html
...

Applied:
http://lists.osgeo.org/pipermail/grass-dev/2008-August/039200.html

No problem to discuss again of course.

Thanks Markus for the links. In the emails I see a lot of discussion about

tab being 8 spaces wide versus some other width. And I see that 8 spaces
for a tab is probably the ideal (at least it was).* However, I don't see
the reasons for having first level of indent 4 spaces and second 1 tab.
This means that first level of indent is 1/2 of a tab? I don't think this
is a good idea.

* If you are using only tabs it really does not matter "how long" tab (in
spaces) is because indentation levels are defined in number of tabs (not
spaces) and the number is natural number (naturally).

Markus

Hello, I occasionally still glance at GRASS e-mails sometimes, and this thread just caught my eye!

On 20/08/14 22:35, Vaclav Petras wrote:

On Wed, Aug 20, 2014 at 5:14 PM, Markus Neteler <neteler@osgeo.org
<mailto:neteler@osgeo.org>> wrote:

    The discussion was in 2008, for some pointers, see

    http://lists.osgeo.org/pipermail/grass-dev/2008-April/037622.html
    ...

Thanks Markus for the links. In the emails I see a lot of discussion
about tab being 8 spaces wide versus some other width. And I see that 8
spaces for a tab is probably the ideal (at least it was).* However, I
don't see the reasons for having first level of indent 4 spaces and
second 1 tab.

I think there was no discussion of it at the time simply because no one disagreed with Glynn's suggestion for 4-space indents! Certainly I have always felt it is a nice length. Any shorter and it is hard to see the indentation at a glance; any longer and long lines can start to disappear off the right-hand edge of your screen, requiring horizontal scrolling, which can quickly get very annoying.

Using a tab character instead of 8 spaces also saves 7 bytes from the length of the file.

This means that first level of indent is 1/2 of a tab? I
don't think this is a good idea.

Well it is no problem if all developers always use 8-character tabs. I agree it can seem a bit "ugly" though. If mixed tabs and spaces were to be banned my preference would always be to replace tabs with 8 spaces (although that would add 7 extra bytes per tab to the filesize!).

* If you are using only tabs it really does not matter "how long" tab
(in spaces) is because indentation levels are defined in number of tabs
(not spaces) and the number is natural number (naturally).

Well it would mean all developers would need to set the tab spacing in their editors to 4 spaces (in order for files to appear the same as now). So it would mean requiring extra effort on the part of the majority of people who use 8-character tabs, just to cater to the minority who like to use tabs of a different length. I'm just playing devil's adocate there of course, but if it had to be changed I definitely think all spaces (a la FFmpeg) is a better option than all tabs...

Perhaps a survey as to the tab settings used by all GRASS developers would be a good idea?

Paul

On Wed, Aug 20, 2014 at 7:10 PM, Paul Kelly <paul-grass@stjohnspoint.co.uk>
wrote:

* If you are using only tabs it really does not matter "how long" tab

(in spaces) is because indentation levels are defined in number of tabs
(not spaces) and the number is natural number (naturally).

Well it would mean all developers would need to set the tab spacing in
their editors to 4 spaces (in order for files to appear the same as now).
So it would mean requiring extra effort on the part of the majority of
people who use 8-character tabs, just to cater to the minority who like to
use tabs of a different length.

You need to have 8 spaces tabs for the files to look correct. If we would
be using just tabs, any number of spaces for tab would be correct. The
style we are using is however this:

while (True) { // level 0
(four spaces) if (a == 5) { // level 1
(one tab) if (b == 6) { // level 2
(one tab)(four spaces) c = 5 // level 3
(one tab) } // level 2
(four spaces) } // level 1
} // level 0

Tell me if I'm looking to wrong files but this is the state of files
indented by the indent script. See attached screenshot of a file after
running grass_indent.sh in editor showing whitespace characters.

I'm just playing devil's advocate there of course, but if it had to be

changed I definitely think all spaces (a la FFmpeg) is a better option than
all tabs...

Or we can of course accept both but now we are not comforting anybody (by
the style standardized in the script) because we are mixing them, and not
only in one file but in the scope of one line. Third level of indentation
is one tab (to get you to the second level) and four spaces (to get one
level up). Now, what is the fourth level? From what I know, you replace the
four spaces by one tab and you are there.

To make myself clear, I don't care how tab is long. I'm even not stating
any preference about using spaces only or tabs only for one file or for the
whole project. What bothers me is that mixing spaces and tabs at one line
does not make any sense as well as one tab used to indent the second
indentation level. And I don't want to introduce this to new files.

(attachments)

grass_indent_result.png

Vaclav wrote:

What do you think?

IMO it's just fine how it is now. I'm quite fond of it with 4 columns
per indentation level and 8 spaces as a tab actually. I would ask to
please not mess with it.

I find all spaces for a 8-column tab in C to be quite wasteful in both
disk space and scrolling time, and thus ugly, not to mention pointless
-- Python cares about whitespace, C does not. Do not apply Python
conventions to C code, and do not ask people to make adjustments to
their text editor.

Please let's focus our energies on the many open bugs in the trac'er
instead of fixing things which are not broken. e.g. WinGrass needs all
the time we can give to it to solve the last 2% of its problems.

regards,
Hamish

On Thu, Aug 21, 2014 at 6:16 AM, Hamish <hamish.webmail@gmail.com> wrote:

Vaclav wrote:
> What do you think?

IMO it's just fine how it is now. I'm quite fond of it with 4 columns
per indentation level and 8 spaces as a tab actually. I would ask to
please not mess with it.

I'm not fine with it at all. 4 columns or 8 spaces for tab are both good

by themselves. But again, this is not what I'm talking about. The problem
is the combining tabs and spaces at one line in different ways to get
different indentation levels.

I find all spaces for a 8-column tab in C to be quite wasteful in both
disk space and scrolling time, and thus ugly, not to mention pointless
-- Python cares about whitespace, C does not.

The fact that C does not care about whitespace does not mean that we are
not using any whitespace or random whitespace, right? We want whitespace
for humans because they care about whitespace and they want rules and order
based on reasoning. I don't consider the current rules reasonable, and thus
I want to change them. For me, the tabs and spaces mixed in one line and
changing spaces to tabs when there is eight of them does not fulfill the
purpose of indentation rules and perhaps the purpose of indentation itself
(in C) -- to improve readability, to be pleasing to human eye, and to be
easy to use.

Do not apply Python
conventions to C code, and do not ask people to make adjustments to
their text editor.

The problem is in fact the opposite, people are applying the "GRASS C

style" to Python code, see #1832.

Please let's focus our energies on the many open bugs in the trac'er
instead of fixing things which are not broken. e.g. WinGrass needs all
the time we can give to it to solve the last 2% of its problems.

As I mentioned earlier, I know about the problem for some time but my

motivation for the change is writing a new code and writing by new people.
I'm explaining people why GRASS GIS is a good platform for developing their
geospatial algorithm and why they, perhaps, might want to contribute to
GRASS itself. When we get to the rules which should be followed, we
inevitably step into the rules for indentation. There is no way of showing
how GRASS can tackle difficult problems and how the system is good and
reasonable when a simple and minor think as indentation is completely
unreasonable and thus not understandable. What's the hope, form the point
of view of a newcomer, that he or she can grasp more important rules? The
result of this is clear, there is no newcomer at the end. I think the way
to fix this is to introduce new reasonable indentation rules for new files.

I think I said enough in this and in previous emails. If you think it was
not understandable, look to the source code, edit a file, use the
grass_indent.sh script and think if the indentation is it is nice, good and
understandable. But I will say one think more to make it straight. If I
should choose between getting a new contributor and not changing settings
of my editor, I rather change my editor settings (and GRASS indentation
rules) right now.

regards,
Hamish

Vaclav Petras wrote:

In other words, if there is some rule there should be some reasoning behind
it. Four spaces for first level and one tab for second level does not make
any sense to me. If old files cannot be changed, let's at least not
introduce bad practice to new files.

The "rules" are that indentation in multiples of 4 columns, and we
don't care whether that indentation is acheived through spaces or
tabs.

--
Glynn Clements <glynn@gclements.plus.com>

Vaclav Petras wrote:

You need to have 8 spaces tabs for the files to look correct.

So? Tabs *are* 8 columns. Just like pi = 3.14159..., c = 299792458 m/s,
etc. This isn't a matter of preference.

Sure, some text editors allow you to configure their interpretation of
tabs. But equally you can just modify the value of M_PI in your
system's <math.h>. Either way, your code isn't going to be much use to
anyone else, and other people's code isn't going to be much use to you.

If someone has their editor configured to something other than
8-column tabs, that's their problem, not ours.

--
Glynn Clements <glynn@gclements.plus.com>

On Thu, Aug 21, 2014 at 11:21 AM, Glynn Clements <glynn@gclements.plus.com>
wrote:

Vaclav Petras wrote:

> In other words, if there is some rule there should be some reasoning
behind
> it. Four spaces for first level and one tab for second level does not
make
> any sense to me. If old files cannot be changed, let's at least not
> introduce bad practice to new files.

The "rules" are that indentation in multiples of 4 columns, and we
don't care whether that indentation is acheived through spaces or
tabs.

So, since we are providing a script and standard for indentation, let's use
only spaces* in this script (rather then enforcing mixing of tabs and
spaces when there is no reason for it).

First level: 4 spaces = 4 columns
Second level: 8 spaces = 8 columns
Second level: 12 spaces = 12 columns

On 21/08/14 17:42, Glynn Clements wrote:

Vaclav Petras wrote:

You need to have 8 spaces tabs for the files to look correct.

So? Tabs *are* 8 columns. Just like pi = 3.14159..., c = 299792458 m/s,
etc. This isn't a matter of preference.

I don't have any specific knowledge, and definitely no religion in this debate, but according to [1] (and I have no idea how valid the author's statements are), your point of view seems to be a bit *nix-centric. In the idea of trying to get more developers for Windows, wouldn't it help to find a "standard" that applies across all platforms ?

Moritz

[1] http://www.jwz.org/doc/tabs-vs-spaces.html

Moritz Lennert wrote:

>> You need to have 8 spaces tabs for the files to look correct.
>
> So? Tabs *are* 8 columns. Just like pi = 3.14159..., c = 299792458 m/s,
> etc. This isn't a matter of preference.

I don't have any specific knowledge, and definitely no religion in this
debate, but according to [1] (and I have no idea how valid the author's
statements are), your point of view seems to be a bit *nix-centric.

It's not so much that my view is Unix-centric, as that the other
popular platforms (Windows, Mac) are rather more willing to discard
long-standing conventions (in some cases, this is meant to cause
problems, i.e. "embrace, extend, extinguish").

Historically, software and hardware which interpreted a tab character
fell into two categories:

1. Hard-coded (or hard-wired) at 8 columns.
2. Defaults to 8 columns, can be configured.

[Note that the Windows console appears to fall under #1; if there's a
way to change the tab width, I can't find it.]

The existence of software which defaults to something other than 8
columns is a relatively recent phenomenon. And it's not as if the
8-column convention will be going away any time soon (e.g. POSIX has
many such references, and is unlikely to make an incompatible change
based upon "fashion").

In the idea of trying to get more developers for Windows, wouldn't
it help to find a "standard" that applies across all platforms ?

There are only two possible standards: tabs are 8 columns, or they're
ambiguous and thus must be avoided.

It's not as if Windows editors can't be configured to use 8-column
tabs (given the amount of existing code that uses that convention,
that would harm Windows users, which isn't the intent).

--
Glynn Clements <glynn@gclements.plus.com>

Vaclav Petras wrote:

> The "rules" are that indentation in multiples of 4 columns, and we
> don't care whether that indentation is acheived through spaces or
> tabs.

So, since we are providing a script and standard for indentation, let's use
only spaces* in this script (rather then enforcing mixing of tabs and
spaces when there is no reason for it).

Some might consider the reduction in file size to be a reason for
using tabs. I have no opinion either way.

--
Glynn Clements <glynn@gclements.plus.com>

I want to add one more perspective to this discussion. In terms of formatting, mixing tabs and spaces looks fine, but when I change indentation levels, my editor (vim) doesn’t like mixed tabs and spaces. For example, I want to change the indentation level from 4 (two tabs) to 3 (one tab + 4 spaces), vim doesn’t like it and hitting backspace deletes only one space. I found some settings to deal with it automagically, but entering after an opening brace does not indent properly yet and I have to manually deindent one level. I couldn’t find any good trick to solve this issue if any exists.

I think, if we want to mix tabs and spaces, we need good support from our editors, otherwise, it can be very annoying to mix tabs and spaces manually.

Huidae

···

On Fri, Aug 22, 2014 at 7:16 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

The “rules” are that indentation in multiples of 4 columns, and we
don’t care whether that indentation is acheived through spaces or
tabs.

So, since we are providing a script and standard for indentation, let’s use
only spaces* in this script (rather then enforcing mixing of tabs and
spaces when there is no reason for it).

Some might consider the reduction in file size to be a reason for
using tabs. I have no opinion either way.


Glynn Clements <glynn@gclements.plus.com>


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Correcting myself… “indentation level from 5 (two tabs + 4 spaces) to 4 (two tabs)”

···

On Sun, Sep 7, 2014 at 8:57 AM, Huidae Cho <grass4u@gmail.com> wrote:

I want to add one more perspective to this discussion. In terms of formatting, mixing tabs and spaces looks fine, but when I change indentation levels, my editor (vim) doesn’t like mixed tabs and spaces. For example, I want to change the indentation level from 4 (two tabs) to 3 (one tab + 4 spaces), vim doesn’t like it and hitting backspace deletes only one space. I found some settings to deal with it automagically, but entering after an opening brace does not indent properly yet and I have to manually deindent one level. I couldn’t find any good trick to solve this issue if any exists.

I think, if we want to mix tabs and spaces, we need good support from our editors, otherwise, it can be very annoying to mix tabs and spaces manually.

Huidae

On Fri, Aug 22, 2014 at 7:16 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

The “rules” are that indentation in multiples of 4 columns, and we
don’t care whether that indentation is acheived through spaces or
tabs.

So, since we are providing a script and standard for indentation, let’s use
only spaces* in this script (rather then enforcing mixing of tabs and
spaces when there is no reason for it).

Some might consider the reduction in file size to be a reason for
using tabs. I have no opinion either way.


Glynn Clements <glynn@gclements.plus.com>


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev