Remove alignment spacing in variable lists and structs/classes

[hostilefork]

One thing I'd ask before a 2.8 formal drop would be if it would be possible to go over all the files and just take out all the alignment spacing.

Reason is, that the maintenance and concern of something like:

int      something;
mystruct somethingElse;

Is just kind of crazy, because of the reformatting it takes when you add a longer-named thing:

int                something;
mystruct           somethingElse;
mylongernamedthing somethingStillDifferent;

Not only is it busywork you may or may not want to do, it also winds up meaning that if you have one functional line of change in the code...you are touching three lines in source control to mess with spacing.

The standard is generally just:

int something;
mystruct somethingElse;
mylongernamedthing somethingStillDifferent;

I happen to use a proportional font and syntax highlighting which makes the above look more along the lines of:

    int something;
    mystruct somethingElse;
    mylongernamedthing somethingStillDifferent;

Which to me calls out the necessary information and fits more on a page. Anyway, in an ideal world we'd be dealing with source code in a more "structured" form where everyone could just view it how they liked...but as long as it's text files I think it's best to do what works best for text file versioning and maintenance.

I'm willing to do the pre-release sweep using a prettyprinting tool to standardize all the files, and that way it can be something mechanical... two spaces is acceptable for indentation if that is the preference (I use 4 in my own code).

[sorenhein]

I see what you mean. I guess I do it relatively consistently (a) in .h files and (b) in function declaration lists. Then I also do it (c) in other places where it "looks pretty" (for some definition of "pretty"). If it become ridiculously indented, then I often don't. (a) and (b) seem doable with filewide tabs. It seems a bit extreme to actively undo it in (a) and (b) where it works reasonably well, I think. Would you settle for undoing (c)? :-) But then I guess that doesn't work automatically.

The other thing is that some of the code still has Bo's style, and I generally only imposed mine when I rewrote large chunks. When I did do something semi-automated, I used "astyle --style=allman --indent=spaces=2 --pad-oper".

[hostilefork]

It seems a bit extreme to actively undo it in (a) and (b) where it works reasonably well, I think. Would you settle for undoing (c)? :-)

Collaborative projects are about compromises. But I really do feel that in the face of type changes and variable name changes it does clutter the version history to adhere to this, and the value is questionable.

"pretty" API documentation is best managed by doc tools that autogenerate something nicer than ASCII with hyperlinks and such. Haven't had occasion to use Doxygen for a while, but it's not terrible and has advanced a bit in the past years...it would seem:

http://www.stack.nl/~dimitri/doxygen/

In other words: attempts to make the .h files pretty are probably secondary to making them proper source files for more readable documentation. So their properties as source and under version control become more important.

For the changes I'd like to propose, it adds type safety to many parameters, and it would sadden me to see those deltas as touching lines they didn't actually touch (now that everything is under versioning). So that means either being sloppy during the dev phase and not fixing the alignments until the release where everything gets touched up...or just eliminating the practice altogether.

Perhaps @bohag could weigh in an opinion on how to do the 2.8 distribution?

[bohag]

It would be nice to have some standard for new code. But it is not that important that it should influence the v2.8 release.

[sorenhein]

I think Brian will have it done in 2 minutes flat with "astyle". As long as I get my indentation/braces, I can live without the spaces!

[bohag]

OK, let "astyle" remove the spaces,