Re: Debian coding style?
uwd38znr@umail.furryterror.org (Amy Fong) writes:
> Is there anybody who actually _likes_ hungarian notation and/or n !=
> 8 space tab? I'm basically trying to collect data points here
> (because those are the only rules that I disagree with that they
> insist on).
Well, one thing to keep in mind overall is the point I stressed in my
earlier post: *consistency*! Now, for a company like Corel which is
used to having absolute control over their code base, that may sound
like a fairly simple proposition: pick some rules and stick to them.
But it doesn't work like that when you're working with the free
software community. Different projects have different rules, and if
you try to enforce your own *internal* rules on external projects,
guess what you lose? That's right, consistency!
Tabs != 8 is going to be inconsistent with almost exactly 100% of the
Linux software out there. And if you use it as an internal rule,
you're going to have to be *very* careful to keep it out of any
external code you may be working on (since it's usually handled
silently by editor configurations). So, IMO, it is a much better idea
to stick with the UNIVERSAL standard of tabs = 8 even for internal
code.
And as for tabs vs. spaces and such, I think Corel might be best
served by this rule: all code *will* be run through indent(1) before
being checked into any code repositories, in order to ensure that tabs
and spaces are handled properly (among other reasons). Then the
programmers don't even have to worry about many of these details,
project managers can ensure stylistic consistency automatically.
As for Hungarian, well, again, consistency should be the rule here.
Despite my own *personal* dislike for Hungarian, I have no arguments
for why a company shouldn't use it for their own *internal* code.
(Unlike the tabs != 8 rule, Hungarian is hard to overlook by
accident.) But again, when you work with external code, you need to
follow the rules in place in that code: use Hungarian when a project
uses Hungarian, and don't when it doesn't. But the fact that there
are so many variations on Hungarian means that most free software
projects don't use it, simply because it's hard to get contributors to
learn the rules for the specific flavor in use on a specific project.
This is all a tricky proposition for a company like Corel, I'm sure.
It's so much easier to lay down absolute rules -- it's usually a great
benefit to junior programmers (whether they like it or not), and
competent senior programmers generally won't mind unless your rules
are outright stupid (which those mostly weren't). But when you're
working with external code, the rule: "be consistent with the existing
style of the project" is a tricky one to explain to the juniors. I'm
sorry, I don't have any easy answers, except to say that the rules
will probably have to become more organic, and you may want to engage
in mentoring or something before (or while) unleashing juniors on
external code.
Management likes to believe that it's in charge -- overcoming this
attitude may turn out to be the hardest part of the Debian-Corel
alliance. The whole idea of shared responsibility with external
entities is always a tough nut to crack, and doubly so when the
external entity doesn't have any middle management of its own to
sympathise or negotiate with. :-)
Bottom line: if Corel chooses any set of rules that don't include the
absolute override: "be consistent with the rules of an existing
project, whatever those rules might be," they're going to create more
work for themselves and for others, and run the risk of creating
purely stylistic forks in the code[1], and forks of any sort are
something we *all* want to avoid.
[2] if Corel sends *me* patches that have tabs=2 and Hungarian, I
*will* remove these warts before merging the patches. No project
under *my* control will ever use those.
If you guys weren't half a continent away, I might even offer the
services of this crusty old senior programmer, who has years of
experience working with the free software community. Alas... :-)
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: