spaces or tabs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

spaces or tabs

ravas
This post was updated on .
Editors have the ability to produce tabs as spaces.
What is preferred for indentation in our code: spaces or tabs?
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

dxli
I prefer to use tabs:

1, 1 character vs 4 characters, say, 1 tab = 4 spaces;
2, force auto indentation, instead of trying manual indentation by playing space

I don't want to enforce it though, after all, we are still too small a group to start coding style conflicts

ravas wrote
Editors have the ability to produce tabs as spaces.
What is preferred for indentation in our code: spaces or tabs?
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

ravas
I will use tabs then; otherwise, it doesn't render indentation properly on github.
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

LordOfBikes
Administrator
ravas,

I see you've started converting whole files from spaces to tabs with your latest pull request, thus I want to put my two cents in.

First, I'm a spaces (4) guy. This is what my experience taught me over the years and what I use in job and spare time coding.
Both, tabs and spaces works fine in probably all modern IDE's and editors. Indent and outdent is no problem, even with spaces. The work flow is the same.

As github uses 8 spaces for one tab, the alignment of wrapped parameter lists is shifted there, what is often used in LibreCAD code. This is a github issue and possibly a local git issue when working in a terminal that uses 8 spaces by default too. When working in the IDE or a git GUI, everything is fine when using 4 spaces per tab.

There is a vast number of discussions about this, however it remains as a matter of taste.

My position is, that even teams of 2 members can work more efficiently when they have some coding style rules.
The LibreCAD code base is already mixed up with tabs and spaces. I think it doesn't make much sense to define rules for the 2.0 code base. Maybe for the 3.0 code. A brief look showed a mixup there too, with a majority of spaces used for indentation.

Until we don't have official coding style rules, I advocate to omit these whole file conversions. They produce a bunch of diffs which hide the valuable changes and possibly bugs too. When it comes to debugging sessions where more than one commit is involved, it is hell to go through all these diffs and find the bad one.

So feel free to use tabs for your work, but please avoid excessive space to tab conversion which produces worthless diffs.

Like I said, only my two cents.

Armin
investing less than half an hour into Search function can save hours or days of waiting for a solution
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

ravas
This post was updated on .
The creation of "worthless diffs" is a weakness of the system,
and is not a strong reason to refrain from making things more consistent.
However, because it bothers you I will stop converting the files I work on.
Note that I did separate the commits so it doesn't interfere with reading the changes I made.
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

ravas
The unfortunate effect of not coming to a consensus is that our published code looks... wacky.

While I like the idea of tab as a unique symbol for indentation,
I suggest using spaces simply because it is Qt Creator's default.
That means newer contributors are more likely to already use this.
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

R. van Twisk
Administrator
In reply to this post by LordOfBikes

> On Sep 21, 2015, at 11:56 PM, LordOfBikes [via LibreCAD] <[hidden email]> wrote:
>
> ravas,
>
> I see you've started converting whole files from spaces to tabs with your latest pull request, thus I want to put my two cents in.
>
> First, I'm a spaces (4) guy. This is what my experience taught me over the years and what I use in job and spare time coding.
> Both, tabs and spaces works fine in probably all modern IDE's and editors. Indent and outdent is no problem, even with spaces. The work flow is the same.
>
> As github uses 8 spaces for one tab, the alignment of wrapped parameter lists is shifted there, what is often used in LibreCAD code. This is a github issue and possibly a local git issue when working in a terminal that uses 8 spaces by default too. When working in the IDE or a git GUI, everything is fine when using 4 spaces per tab.
>
> There is a vast number of discussions about this, however it remains as a matter of taste.
>
> My position is, that even teams of 2 members can work more efficiently when they have some coding style rules.
> The LibreCAD code base is already mixed up with tabs and spaces. I think it doesn't make much sense to define rules for the 2.0 code base. Maybe for the 3.0 code. A brief look showed a mixup there too, with a majority of spaces used for indentation.
>
> Until we don't have official coding style rules, I advocate to omit these whole file conversions. They produce a bunch of diffs which hide the valuable changes and possibly bugs too. When it comes to debugging sessions where more than one commit is involved, it is hell to go through all these diffs and find the bad one.
>
> So feel free to use tabs for your work, but please avoid excessive space to tab conversion which produces worthless diffs.
>
> Like I said, only my two cents.
>
> Armin

I agree here with Armin,

I also would like to see spaces instead of tabs.
This allows for a better alignment of multi line methods and it's variables, some type of comments and what not.

I believe a long time agin in the LibreCAD 1 era I did a conversion to spaces...time flies...

Ries
Reply | Threaded
Open this post in threaded view
|

Re: spaces or tabs

ravas
In reply to this post by LordOfBikes
Regarding the pollution of commits with white space changes,
it seems the GitHub solution is for reviewers to add ?w=1
to the end of the url.
https://github.com/blog/967-github-secrets

I'm not sure why they don't just add a button for that...