On 10/09/08 14:49, Thorsten Behrens wrote:
> ...
Hi Thorsten,
Sorry for taking some time to answer, it seems my newsserver sometimes
ate messages....
> 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.
I will try to move the details out of the main description and add
references to the coding standards where possible.
> - 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.
Yes, I would love that too, however my idea of how this is supposed to
look like is only vague. Maybe someone from RelEng might step up and add
a few lines about how a "wellformed module" is layed out?
> Maybe keeping filenames all-lowercase is a bit anachronistic -
> but keeping them [a-zA-Z0-9.-] seems still crucial.
True. OTOH, for example Subversion has some interesting behaviour with
upper/lowercase filenames on Windows (commit "svn mv SomeFile.cxx
somefile.cxx" on unix and update on Windows).
> I'd relax the strict .hxx|.h rule a bit, taking udk headers for
> example, which split templates up into separate declaration &
> definition files
Okay.
> - 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*.
Well, lets just call them recommendations. If you do not have a
stylistic preference on a topic, you could use those for guidance.
> - 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?
I removed the camtrip.org-link. Please feel free to add recommandarions
about SAL_NO_VTABLE, SAL_DLLPUBLIC_EXPORT, SAL_DLLPUBLIC_IMPORT and
SAL_DLLPRIVATE.
> > 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? ;)
I liked that Emacs operating systems, but installed vim to have a proper
editor ;-) . While it is true that code by one person with any sense of
style is perfectly readable, it also true that 200 persons with any
sense of style working in the same codebase will lead to documents
formatted different every five lines, severely reducing readability.
Have Fun,
Björn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
