[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Script to count tab spaces in source files
From: |
ThomasK |
Subject: |
Re: [Simulavr-devel] Script to count tab spaces in source files |
Date: |
Sat, 07 Jan 2012 10:49:52 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 |
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