Re: [Simulavr-devel] Script to count tab spaces in source files

[ThomasK]

Hi Petr,

just to answer, not to make the "next battle in the war": :-)

> Readability and parsing were not affected. There are other, more
> important reasons for tabs.

Readability IS affected if somebody looks to a source with tab space 4 
(for example) and it was formatted in a few lines with tab space 8 
before. Just as a example. I remember seeking a bug (not in simulavr) in 
a project and it took some time to realise, that somebody before has 
used a wrong indentation because of such problems before. And, he has 
set a brace on a wrong place because of this. And I have overseen this 
in the beginning to and was wondering. With correct indentation it was 
easy to see the mistake.

> The word "soft-tabs" is new and not used. In fact googling that leads
> to a Viagra tablets page.

Ok, not this blue pills or which color even! :-)

> I think that people on Earth mostly agree to keep some coding style
> and are willing to lose some freedom. However people on Earth do not
> agree what coding style to use. Also they do not agree (to lesser
> degree) on whether files/classes/functions are allowed to differ in
> style if they are internally consistent.

Ok, then here some coding styles:

Use no tab character, if it's not necessary. Especially not in formating 
source code. Use 4 space character's instead for indentation.

Line length should not be more than 80 characters. For the most 
contructs it's possible to use a line break. (It's not so strict, but 
300 characters lines are not really readable. :-) )

Where to set braces: (as example)

function(void) {
    ... body
}

or:

if(condition) {
    ... body
} else {
    ... else body
}

There is (as I've seen) one exception for class constructors because of 
initializers and line length, there the beginning brace for the body can 
be on first position on the next line. (because it's easy to oversee the 
starting brace, if on last column after a list of indented initializers 
and the well indented body)

Klaus wrote about naming style: under_score_names vs. CamelWriting. I 
think, we have mixed this some times. And, as my experience, this is 
also a battle field in the holy war of right formated source. :-)

To give a rule: :-) CamelWriting for function/method/class names and 
variables. Functions and method start with a upper case letter, 
variables with a lower case letter. Constants (as defines or part of 
class declaration) in upper case with underscores. For function macros 
the same as normal functions. If somebody starts to heavy change a 
module, it should be changed in a separate commit before. (so we get 
this clear step by step)

Some other suggestions?

cu, Thomas