• The zipped JavaDoc API
  
• The JAR of the reference Java 5 implementation
  
• The zipped NetBeans package containing the sources of ODFDOM v0.6.

tags: api architecture code development netbeans odf opendocument software specification sun xml

ODFDOM is the name of the upcoming free OpenDocument framework sponsored by Sun Microsystems Inc.

It will be the next evolutionary step after AODL and Odf4j. Designed together with their architects with the intent to provide an easy lightwork programming API for the ODF developer community. ODFDOM is meant to be portable to any object-oriented language.

The first pre-version of the Java 5 reference implementation of ODFDOM is planned to become available under LGPL3 in May 2008.

Please find further detailed information in the OOo Wiki.

 

tags: api architecture code development netbeans odf opendocument software specification sun xml

Sometimes the question occurs, if programming is an art, a craft, a science or what else?

Art produces beauty, science produces knowledge, a craft produces practical things you can use.  So, I came to the conclusion that most likely programming could become a craft ... but is not yet.

A craft like carpentry or shoe-making is based on a large set of established, commonly acknowledged and proven-to-be-useful knowledge and practices. In programming, knowledge still changes rapidly, practices often contradict each other and neither of them are commonly acknowledged. 

• Is it preferable to write lots of documentation about your software or is better to rely on the code as the only truth?
• Put the opening curly brace right on the top - or left into an extra line?
• Do templates (in C++) make your code more readable or more unreadable?
• Write tests first, code later - or the other way round?
• "Write everything const-correct" versus "Const? - Never heard, my programming language doesn't have such rubbish".
  

About any of those questions one could say (with only little exaggeration): Two developers, three opinions, four ways to do it.

The same applies to many basic questions of programming. Our craft-to-be is still such young that we need to continuously exchange knowledge and practices, often and everywhere, in order to build up that set of commonly acknowledged basics that older crafts already possess.

I added two pages to the OpenOffice.org wiki, about Code Quality and Defect Prevention, that may trigger some more of such discussions to approach commonly accepted knowledge and practices.

tags: code openoffice.org quality software

In December I wrote about the OOo coding standards.  Having standards is fine, but how to get them into my code? Studying them, sitting in the spring sun in a coffeehouse? Put them under the pillow for night? Trying to memorize during metro drives?

Actually, none of these sounded convincing enough.  So some OOo developers at Sun in Hamburg started to use them in weekly code reviews. Every week two people join and have a look at each other's code, using about ten of the coding standard's rules.  Find the details here.

Actually, this was fun (at least sometimes). We saw code from other projects, extending our understanding of various parts within OpenOffice.org, learned some useful tricks from our review-partners, and - last but not least - without really noticing it, we meanwhile know a large part of the coding standards. With some minor adaptions such reviews should also be possible among developers in different locations. May be you'd like to give it a try.

tags: code quality software

Hello, GullFOSS readers! This is my first blog entry here. My name is Nikolai Pretzell, I am part of OpenOffice.org since it started and work for Sun on code quality and on the code documentation tool Autodoc.

Defect prevention is a favourite field of interest to me. Instead of relying on testing to hopefully find a high percentage of bugs, what could we do to avoid introducing them in the first place? Among the many reasons for introducing defects, I want to mention two:

• C++, the programming language in which most of OpenOffice.org is written, is quite complex. It allows many things that pass the compiler, but are not helpful for producing correct and maintainable software.
• The difficulty to understand code by other authors, especially in such a huge code base as in OpenOffice.org. ( And yes, the „other“ author may well be myself – a few month later.)

One possibility to address these are coding standards. Not standards that describe conventions, or to make things prettier. But standards that collect what by today's knowledge is best practice when writing OpenOffice.org code. Idioms that prevent potential bugs, make code easier to understand and less dangerous to change, habits that lessen the danger of oversights, rules that ensure correct use of dangerous C++ features.

So, Matthias Huetsch, Thorsten Behrens and me teamed up and started to collect what we think might become coding standards in the sense described above. We had a few ideas what the requirements for such standards were:

• They should contain only the most important: what indeed reduces the probability of defects.
• They should reduce the number of possibly wrong choices when using C++.
• They should increase code maintainability, making changes easier and less dangerous.
• We wanted them to be usable for code reviews. As it is not possible to apply long and complicated texts in one review session, we decided to split the standards in topics. Each topic should contain a manageable number of issues (which we assumed to be between 2 and 8).
• Each topic's issues should be described clearly and concisely on a one-pager that can be printed out (e.g. to be used in a code review). More detailed background information would be available in a separate location.
• Free of contradictions.

We drew from various resources, most important were texts of acknowledged C++ experts (e.g. Herb Sutter, Scott Meyers, Andrei Alexandrescu), or software maintainability and refactoring (e.g. Martin Fowler), successful projects (the boost project's coding standards) and the existing OpenOffice.org coding guidelines.

Find the current state of affairs in the OpenOffice.org wiki.

Still, lots of clarifications, added rules, removed rules, added background information etc. remain to do. And this is where we would be happy to get your comments and trigger some discussion, that at last the standards might become a real help to OpenOffice.org's developers daily life. The best location for comments may be the discussion pages in the wiki or – for more general issues - the dev@openoffice.org mailing list.

tags: code quality software