1. The COSMO Coding Standards Some Highlights
COSMO Working Group 6: Reference Version and Implementation
Working Group Coordinator: Ulrich Schättler

2. Contents Activities from the last year
Some highlights from the document
Software Maintenance and Quality Control
Release Planning
Implications on daily work
COSMO General Meeting 2011

3. Activities from the Last Year
First draft from August 2010 was followed by a WG 6 discussion at the GM in Moscow
Further drafts in January and April; submission to STC Meeting in April
Discussion within STC resulted in some comments (role of SMC, STC)
Discussions and meetings with CLM group
Discussion within SMC Meetings in January (Zürich) and July (web conf)
„Final Draft“ (now called Version 1.0) from August 2011 submitted to STC for acceptance
NOTE: The „COSMO Coding Standards“ are mainly written for the COSMO-Model and the INT2LM, but are applicable to other COSMO Software. There are appendices for the other codes like fieldextra.
NOTE: The „COSMO Coding Standards“ are also discussed within the CLM Community, but (latest news) not accepted at the moment
Problems for CLM:
which management body decides on CLM developments
who decides on contents of unified releases
COSMO General Meeting 2011

4. Some Highlights from the Document
Coding Rules: try to give the code a „common look“ and improve readability
Documentation: The following documents have to be available for new / modified code:
internal product documentation: code has to be structured in meaningful, documented units / sections
external product documentation: scientific documentation and user guide (also: implementation documentation)
process documentation: documentation of the changes for version history and changes log-file
documentation has to be written such that it can be taken over to the existing documentation (english, latex)
Implementation Issues: still has to be completed
Interfaces: will be described in the Implementation Documentation
COSMO General Meeting 2011

5. Software Maintenance and Quality Control
Codes are maintained in a version control system (VCS)
Code within the VCS is „official code“, all other code (not in the VCS) is „private code“
Each version in the VCS gets a certain status
development: intermediate versions only given to the developers for cross-checking
test: versions given to special test users to conduct extensive tests (different configurations, domains, etc.)
release: if a version passes the tests successfully, it becomes a release and is available to all users
COSMO General Meeting 2011

6. Software Maintenance and Quality Control
How can a contribution („private code“) become part of the VCS („official code“)?
This is specified in Sect. 6.2: Rules for the implementation of changes.
These rules are closely related to the „Development Process“, described in Chap. 2 of the Coding Standards
The most important steps are outlined in the following
Some helpful definitions
STC: Steering Committee
SMC: Scientific Management Committee
TAG: Technical Advisory Group
SCA: Source Code Administrator }
„The Management“
COSMO General Meeting 2011

7. Software Maintenance and Quality Control
Steps of the Development Process
Comments
The Idea
can be initiated by everybody (individuals, WGC, SMC, Universities, CLM), but should be discussed with „relevant people“ (code owners, WGC)
has to be submitted to „The Management“
Development of software without formal restrictions to prove usefulness of the idea and the changes. This will be a „private version“.
(But would be helpful, if Coding Standards are taken into account)
First Management Decision
Management decides, whether the idea is inline with scientific / technical planning. If so and if usefulness has been proved, it is included in the Planning for Future Developments.
A plan for the further development has to be set up. If COSMO resources are used (e.g. for a Priority Project), Management has to decide about that
COSMO General Meeting 2011

8. Software Maintenance and Quality Control
Steps of the Development Process
Comments
The Development
Now developing and testing has to be done according to the COSMO Standards. This is still done with a „private version“.
See following slide „Implication on daily work“ for more details.
For testing, a technical and a meteoro-logical test suite will be defined soon.
The amount of testing depends on the kind of changes.
Results of the tests have to be published „appropriately“ (presentation, Newsletter, TR, …).
Second Management Decision
Management checks the results of the tests and conformance of technical requirements. If all issues are satisfied, the change is included in the Release Planning.
The Release Planning defines an intended version number and date for implementing the changes into „official code“, i.e. the VCS.
COSMO General Meeting 2011

9. Software Maintenance and Quality Control
Steps of the Development Process
Comments
Official Implementation
The code together with the documentation is given to the SCA, who implements it into the VCS.
The official code is given to the developer again for cross-checking.
Depending on the kind of change, new versions will be „development“- or „test“-versions.
COSMO General Meeting 2011

10. Release Planning
„The Management“ administrates a list of contributions, the Planning for Future Developments
This list contains the contributions which are still under development and do not fulfill all requests yet
„The Management“ administrates a second list, the Release Planning
This list contains the contributions for which development is ready, fulfills all requirements and can be taken over to the „official code“
For these contributions a date is specified, when the corresponding version will be available
COSMO General Meeting 2011

11. Implication on Daily Work
Are you a „Real Programmer“?
Real Programmers don‘t do design and write specifications: Users should consider themselves lucky to get any programs at all and take what they get.
Real Programmers can write five page long DO loops without getting confused.
Real Programmers like Arithmetic IF statements and GOTOs: They make the code more interesting.
Real Programmers don‘t document: If it was hard to write, it should be hard to read. And usually the code is obvious.
Real Programmers don‘t test: If there is a problem, it can be patched into a working version in „only a few“ 30-hour debugging session.
Real Programmers don‘t use debuggers: They can read core dumps.
We do not need Real Programmers
COSMO General Meeting 2011

12. Implication on Daily Work
It would be very beneficial for all of us, if the daily development work is done according to the COSMO-Standards:
„The source code provided is properly designed“
„The source code provided conforms to the coding rules“
„All source code modifications are documented“
„All changes have been tested. The results are published appropriately“
„A code responsible person is available in the future“
COSMO General Meeting 2011

13. Thank you very much for your attention 05.09.2010
COSMO General Meeting 2011