Emil Cataranciuc wrote:
> I was reading Configuration Management Plan I have found that Version
> numbering
> guidelines are not respected.
Specifics?
> Also I was wondering, wouldn't it be easier to use tabs instead of spaces for
> indentation? I am asking this because at least in VIM a 4 space wide tab
> indent still will be a tab (you can set it for 8 and it will be 8 or anything
> else... 2). But with spaces it is not the same thing, it is more difficult.
> Why to use spaces?
> According to the Coding Standards, in the same plan, the coding style is K&R
> (although there is a minor mistake, in the plan. K&R recommendation: "Declare
> function names, return types, parameter types and names all on the one line,
> if you can.") but it is not followed. Again, why is that so?
>
> In the end I wanted to ask if it will be OK if I will use tab indentation in
> FLTK 2 source code since almost nobody develops it. Further more, project
> Coding standards states this: "If you use tabs, they must be set at every 8
> character columns;" which means actually no body should be against it.
>
> I don't know if Coding standards are followed in FLTK 1.3 so you may just
> think of this reply as food for brain (How to make others or ourselves to
> follow the standards? :-) ).
The CMP was adopted years after a lot of FLTK was written already,
so due to legacy, there's some code not yet to standard.
There's a desire to not change old code to avoid making diffs
that making it hard to track regressions across commits.
Also, some code comes from other sources, and in those cases,
its not worth while to conform the code to the CMP to make tracking
diffs from the original source readable.
All new code should follow the CMP.
> P.S. K&R coding style also recommends tabs for indentation, not spaces. :-)
The FLTK coding style is not K&R, and purposefully defines tabstops
to not be anything other than 8.
The FLTK coding style seems to have a strong desire to keep the code
width and height as short as possible, hence the 2 space indent and
the rigorous use of dangling open braces, including on all
functions/methods/classes/structs, which makes it somewhat unique.
I'm sure most of the devs don't code in FLTK's style, including me,
but when you work on an established project, you follow its coding
rules.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
