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

[Petr Hluzín]

On 7 January 2012 10:49, ThomasK <address@hidden> wrote:
> 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.

Readability is affected if tabs and spaces are mixed in the same
function. It is NOT affected if only tabs or only spaces are used in a
function. I protested about the statement "it was necessary to use tab
character" for assembler. Both ways are acceptable for assembler. Even
if only tabs were used for assembler and assembler is obsolete, it
does not make tabs obsolete. The assembler argument is invalid.

People who prefer tabs do not mix indenting by spaces with indenting
by tabs (at least in the same function). The whole point of tabs is to
allow people to set any tab size and have the source formated
correctly, changing tab-size would not break anything.

> 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 bug existed not because someone used tabs, but because someone
mixed tabs and spaces in the same function. Nobody does that
intentionally and no indentation style is more likely to break. If the
code used all tabs in the function, the bug would not exist.

I wonder why I have to say that.

>
>> 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:

You do not get it? People cannot agree on indentation. The arguments
for spaces have been said decades ago and refuted decades ago, the
same goes for tabs. People on Earth cannot agree which one is better,
not even simulavr developers can.

I use tabs because all other projects I participate use tabs and my
IDE is not able to detect which indentation style is used in a current
source. (It is even worse: the settings is global, not per project or
per file.) I try to be consistent in existing code (and fix myself if
I get it wrong) but I use my IDE's default indentation for new
classes. (Nobody ever edited the new classes anyway.)

>
> Some other suggestions?

When editing existing function use existing style for everything. When
adding new code use indentation you like.
I have no preference on braces, line length, camel case. (Well, my
diff-viewer does not show underscores, so "lorem_ipsum_dolor" looks
like "lorem ipsum dolor", not a big deal.)

Too much talk, too little code so far.

Obligatory meaningless emoticon: :-)

-- 
Petr Hluzin