On Thu, Oct 09, 2008 at 12:02:46PM +0200, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: > OpenOffice.org has these Coding Standards: > http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards > > As a new member in the writer team I tried to find some additional > conventions that are current (good) practice. The results incorporating > the feedback from other members of the writer team can be found here: > http://wiki.services.openoffice.org/wiki/Writer_Code_Conventions > > Since the effort to codify some of the conventions tacitly agreed upon > was generally well received, I thought I might post it as a inspiration > for all OOo devs. > Hey Bjoern,
I generally like the idea of documenting intra-module coding conventions (as sadly, OOo has quite a range, stylistically, across different modules). That said, as seemingly the listed conventions go beyond existing Writer code (i.e. the parts that suggest refactoring, and the 'general' section), and therefore might have general applicability for the OOo code base, let me point out a few problems: Generally, the list seems fairly parallel to the coding standards, there are places where coding standard items are just repeated or refined (e.g. when to make a header external, namespaces, encapsulation, pimpl) - I would love to have this cross-referenced, or even moved to the 'details' section of the coding standard. This would improve the coding standards digestability, shorten your list, and save people generally aware of the coding standards some reading time. Some misc stuff: - I like the module organization section, but would add more, like e.g. the convention of building libs one directory up (for Writer), what generally the util & prj dirs are for & what they should contain. Maybe keeping filenames all-lowercase is a bit anachronistic - but keeping them [a-zA-Z0-9.-] seems still crucial. I'd relax the strict .hxx|.h rule a bit, taking udk headers for example, which split templates up into separate declaration & definition files - the formatting section is probably the most controversial one (and that's one of the reasons we didn't specify that in the coding standards). Either skip it as well, or at least refrain from catering for tools like lxr (which is obsolete now anyways). The most frequent reader of the code is still you, and your fellow devs (using a proper editor) - strive to make code readable *there*. - in the general section, why the reference to cantrip.org? I fail to see the connection (though deriving virtually from an interface does have its merits). Also, recommending SAL_NO_VTABLE for interfaces seems beneficial. - maybe some words about SAL_DLLPUBLIC_EXPORT/SAL_DLLPUBLIC_IMPORT/ SAL_DLLPRIVATE in the encapsulation part? > None of the conventions are obligatory for anybody, of cause, but they > might make life a bit easier for all (especially for newcomers). > Yes, definitely. And well worth getting Writer (and other modules) closer to this. But I still have mixed emotions about the minutiae of formatting - why not simply referencing http://wiki.services.openoffice.org/wiki/Editor_Emacs for people that use a proper editor, and otherwise acknowledging that code written by people that have *any* sense of style is generally perfectly readable? ;) Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
