[GRASS-dev] Tabs and spaces in C code

[Vaclav Petras]

On Thu, Aug 21, 2014 at 6:16 AM, Hamish <hamish.webmail at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140821/5f1c6b17/attachment.html>