Hi all,
What I have read ( I read all the thread) is very interesting, and
full of good things, but if I can, they are IMO two - at least -
problems ( and I come lately, sorry).
My purpose is to contribute to the debate first, and what follows is
only my little experience. Of course everything is maybe not always
interesting .. I sometimes am verbose ... :-)
Let's imagine I'm a new dev willing to contribute to OpenOffice.org :
[H] : like common people who want to help, I do have C/C++ background
( something like 3 to 10 years of coding something somewhere)
- first question : where are things ? How is organized
OpenOffice.org code ?( build OpenOffice.org can really help here )
- second question: what is the design of the feature I want to
contribute ?
- third question : how write code ? What are the guidelines ..who
contact, how submit patches .. ( )
Note : here is the point of the thread
- fourth : is OpenOffice.org really a free project ? (was : why is my
code always refused ? I found a lot of code written with foots in
OpenOffice.org source code, and mine is not accepted. Immediate
reflex : I give up )
Facts: because I didn't find the answer to the first question(s), I
do like 1 developers over 2 did -> I give up
For Mac OS X port, we lost 1 over 2 new devs, willing to help us,
this way, and I have to use a lot of energy and must take care every
day about that.
So, I'd suggest to separate the analysis in two points ( but if you
are only interested by Coding Guidelines, you can do a long jump to
Point 2)
Point 1 : new devs *don't know*, and *don't understand* how
OpenOffice.org code (often more in fact) is organized :
- not enough informations about OpenOffice.org code design is existing
- OpenOffice.org developers most of the time, DO NOT document the
code *while writing the code* (please add immediately what does exist
as resource in Coding guidelines.sxw ! )
"Document the code" doesn't mean include comments in the code, but
provide a document explaining the design and the hidden ideas, with
most important things, reasons of choices ... constraints ..etc.
Currently painfull.
Several examples to illustrate, from my own experience :
1) I wrote some little parts of code, and every time, it was a
nightmare to find information relative to OpenOffice.org *design*.
e.g. I had to understand scp2, vcl and makefile rules to write some
code in vcl for aquacolors cws. Estimated time needed : 2 months
for all the cws
After some time, one of the most helpfull informations came from
Stephan Schaefer ( after I *intentionnaly* did a mistake to make
things move a bit), Joerg Barfuth (scp2) and Oliver Braun, who sent
me a code snippet about Boootstrap::Something() use. I understood
immediately how use it once I read.
While I wrote the cws code, I wrote a short document, with enough
information to retrieve the "spirit'" of the changes : http://
eric.bachard.free.fr/mac/aquacolors/documentation/
maquacolors_dev_notes.pdf
A separate document has been written for users : http://
porting.openoffice.org/mac/Howto_OOo_2.0_MacOSX_english.pdf
2) current page about directories roles in the wiki is *really*
great. But this is just an entry point, with nothing behind =>
needs some love
e.g. yesterday (yes ), for a new dev willing to help us, I was still
searching where find Drag and Drop relative code (not only dtrans) :
nothing AFAIK, is existing describing how things are organized =>
same for a lot of other parts
3) I think I now have a more clear ideas on how vcl module works, and
can explain to a new developer what can be found, and where, in
several hours of discussion (less is difficult), to give this dev
some "autonomy". FYI, it took my 5 months to read and read and try
and build and build to understand a bit the vcl thing.
My feeling : since we described everything we undesrtood in vcl, new
devs are coming on Mac OS X port. Some confirmed since.
Point 2 : every time I found the info relative to Point 1, the code
was IMHO understandable ( even for me with my little C++ knowledge ),
but this can be improved
So, I'd say the code is IMHO secondary, means less important that
Point 1 in the problem : any dev learning C/ C++ can understand, and
if not, ask to other devs should be helpfull.
If this can help, my tool was (and continues to be):
CodingGuidelines.sxw. I even printed it. This is a main document IMHO
( doing a link with academic C++ , OpenOffice.org code and real life )
The exception was : strings and C++ in OpenOffice.org ( ok, I found
code snippets since)
My opinion: I completely agree with your proposal, and this is a
very good thing to organize and continue.
You can count on me to help you. At least asking a lot of questions :-)
+1 for the update on the wiki (well adapted for that)
+1 for the new entries OpenOffice.org relative, with samples
-1 for a new C++ list of best practices : I already got the
Stroustrup's book (and will continue to learn it)
+1 for Pierre Andre remarks, fulll of sense
+1 for the argument : tabs are evil :-)
To complete, as suggestion, we should add keywords (or sub-
categories) in the wiki description like :
- knowledge only
- practical
- tips ( good examples in the code )
- autonomy ( idea to improve )
- tools ( interaction between code and tools, how compile and test
my code ... )
- resources ( people, code snippets , where/how find/join us,
bibliography ... )
- (complete)
But don't forget the first point: we currently continue to lose new
devs regularly ...
Thanks to the one who have read until here :-)
Eric Bachard
BTW: http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards/
General_Coding#Clear_Origin_of_Local_Data_.28LocalData.29 seems to
need a lot of work
Le 12 déc. 06 à 16:13, Thorsten Behrens a écrit :
Hi folks,
complementing Nikolai's GullFOSS entry
http://blogs.sun.com/GullFOSS/entry/quality_and_coding_standards
I'd like to draw your attention to a revamped version of the OOo
coding guidelines (with the old one getting of age - ~4 years).
We (Nikolai, Matthias H. and me) thought an update and a move to the
Wiki might be in order, and doing that, we went and scanned/re-read
larger chunks of literature about the topic (Lakos,
Sutter/Alexandrescu, Fowler, to name a few) - and then condensed the
material into 19 separate topic areas, with a handful of rules each.
Compared to the old guidelines, the plan is to make this one
significantly easier to digest & use in day-to-day coding (as people
can start small, like using one or two topic areas in the
beginning). If you're a C++ coder - please give it a try:
http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards
Got an impression? Great. Here comes the catch: we need your input to
improve this further, in a very broad sense. We need more background
information, examples, and maybe external links on the rule details
pages (each rule is basically just a tagline, with a one-sentence
summary of the content). We need your opinion about relevance (or
irrelevance) of the rules. And we need to know if (by your opinion),
we've forgotten an important one. Just use the wiki discussion pages
of the respective rules, or simply add your content.
Why should you bother? Well, because OOo is complex enough by itself,
and having a bit of guidance in the land of C++ should be helpful to
almost everybody, especially for people new to the project. At the end
of the day, getting into the habit of checking your code against (some
subset) of coding rules might even make you spot a few other bugs here
and there - improving the quality of code newly introduced to OOo.
Thanks for listening, and eagerly waiting for your feedback!
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
