Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Consistent indentation rules #220

Open
kostrzewa opened this Issue · 4 comments

3 participants

@kostrzewa
Owner

I've been wanting to bring this up for a while now because it makes code much easier to read for everyone. Could we please agree to consistent rules for indendation? Personally, I'm partial to 2 spaces, no tabs. It is a sufficiently big indent to clearly separate levels while beeing conservative in regards to horizontal space. With a good editor using spaces instead of tabs is really not annoying at all.

The only drawback (in my opinion) comes from editing makefiles where one needs to use real tabs for the rules of a target. However, these can be produced by entering "verbatim mode" in VI(M), for instance.

f(in) {
  int n;
  n = in;
}
@urbach
Owner

who is using tabs?

@kostrzewa
Owner

I've found a few of your routines which had a mixture of spaces and tabs. See for instance ndrat_monomial.c line 104. There are three tabs to begin with and then five spaces.

In other instances horizontal aligment is really bad as a consequence.

@urbach
Owner

Im always using xemacs for indentation, so no idea where the tabs come from. Usually xemacs does it with spaces.

@deuzeman
Owner

How about we create an astyle file and commit it? There's probably going to be instances of broken indentation conventions afterwards, but it'll be easy to fix at least. With SVN, there used to be the issue that any file visited by astyle would be marked as modified, but it shouldn't be an issue with git.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.