Domingo Alvarez Duarte wrote:
> Now that you alert me about coding standards I did ask my friend google
> and he told me about this tool:
> http://invisible-island.net/bcpp/bcpp.html
>
> It's a small c++ code beautify (60KB on win32) that do nice job like
> changing spaces by tabs and other things, why not adopt it as the
> official tool to format source code, this is a job done easy by the
> computer and guarantee a real uniformity !
When first starting on FLTK, I offered to bring all the code into CMP
conformance, but there are several things that make this undesirable
and hard:
1) The giant code diff that makes backtracking changes a giant
pain.
Often we diff modules against code that is 4 years old to
try to
find where a bug first surfaced, and then trace the sequence
that
led to that change.
2) It's actually a big job to do all the code, and do it
properly.
Some code we can't change because it's regularly pulled in
from
external projects (JPG, XUTF8, etc)
Although it sounds easy to just run indent(1) or similar beautifiers
on all the code, they can also totally /wreck/ purposeful commenting
and carefully formatted code/comments/indenting which are there for
purposes the beautifier won't understand.
I rarely use those tools unless the code being changed is a total mess,
or if I want to bring two revs of code where indenting was changed into
a common formatting just so I can read them or diff them properly. But
still apply changes in the style the code exists in.
With FLTK being a public project, I've evolved to just 'be flexible'
when it comes to reading the code, and setting up tools that work
with the format it's in.
The rules I've sort of evolved regarding indenting on FLTK is:
1) When adding new code, follow the CMP as much as possible.
Be receptive if people point out indent problems in your
code and fix them.
2) When other people recently added code that /isn't/ to CMP,
let them know.
They might have forgot, didn't know, or used an editor that
had unknown
settings (ie. on a new machine).
3) When making fixes, in general I leave existing code alone as
much as possible,
with the following caveats:
o I'll fix code indenting if it misrepresents code flow.
(This is different then making 'style' changes)
For instance, I'd definitely change this:
for (.. ) ; // forever loop
do_something(); // BAD: indent implies part of loop, but isn't
more_stuff();
o Make /separate/ check-ins if lines are changed for
indent only,
where no code behavior was modified.
o In general I try /not/ to make style changes that
would generate large
multipage diffs, unless that module was part of a
purposeful code cleanup effort.
(like when we were cleaning up the UTF8 code being
merged into FLTK1.3
for doxygen, where large diffs were being expected
anyway)
4) Modules that come from other packages (JPG, PNG..) that
regularly
get imported into FLTK we don't bother bringing into FLTK
conformance.
Mostly, code style/indent changes make more trouble than they solve.
As much as possible when making fixes to existing modules where the code
is obviously waay out of conformance, I'd rather make the code changes
/in that style/ rather than have to convert all the code to CMP, or
insert new code that follows the CMP but looks out of place in the
rest of the module. (Leave the indent fixing for some other day when
the module is targeted for a cleanup after its been idle
development-wise)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
