Tabs and spaces in C code

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Tabs and spaces in C code

wenzeslaus
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
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.

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

wenzeslaus


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



_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Markus Neteler
On Wed, Aug 20, 2014 at 10:21 PM, Vaclav Petras <[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

wenzeslaus
On Wed, Aug 20, 2014 at 5:14 PM, Markus Neteler <[hidden email]> wrote:
On Wed, Aug 20, 2014 at 10:21 PM, Vaclav Petras <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Paul Kelly
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 <[hidden email]
> <mailto:[hidden email]>> 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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

wenzeslaus

On Wed, Aug 20, 2014 at 7:10 PM, Paul Kelly <[hidden email]> 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.

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass_indent_result.png (50K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

hamish-4
In reply to this post by wenzeslaus
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

wenzeslaus
On Thu, Aug 21, 2014 at 6:16 AM, Hamish <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Glynn Clements
In reply to this post by wenzeslaus

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Glynn Clements
In reply to this post by wenzeslaus

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

wenzeslaus
In reply to this post by Glynn Clements

On Thu, Aug 21, 2014 at 11:21 AM, Glynn Clements <[hidden email]> 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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Moritz Lennert
In reply to this post by Glynn Clements
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Glynn Clements

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Glynn Clements
In reply to this post by wenzeslaus

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Huidae Cho
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 <[hidden email]> 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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tabs and spaces in C code

Huidae Cho
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev



_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev