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

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

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 05.09.2010 COSMO General Meeting 2011

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 05.09.2010 COSMO General Meeting 2011

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 05.09.2010 COSMO General Meeting 2011

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“ 05.09.2010 COSMO General Meeting 2011

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 05.09.2010 COSMO General Meeting 2011

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. 05.09.2010 COSMO General Meeting 2011

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. 05.09.2010 COSMO General Meeting 2011

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 05.09.2010 COSMO General Meeting 2011

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 05.09.2010 COSMO General Meeting 2011

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“ 05.09.2010 COSMO General Meeting 2011

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