Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 392

News	FAQ
Search	Home

Implementation

During implementation, the following policies are applicable:

1. Coding practices: Coding conventions, standards and practices are set by the technical leader, on advice from the QAG.

2. Project compiler: The project has a policy of a single project compiler in order to ensure maximum build stability so that applications can be delivered on time to end-users. All developers are expected to use the project compiler for development, and all code checked-in needs to compile with this designated compiler. The project compiler is set periodically subject to the following criteria:
   • An improvement over the current project compiler in reliability, language support or optimization, or a combination thereof.

   • Operation on all consortium development architectures, or those planned for the release.

   • Inter-operability with current development tools used in the project.

3. Secondary compilers: Secondary compilers may be designated by the technical leader if resources are available for their support. Code only needs to be checked against the project compiler, however, as noted above. A designated group will be responsible for ensuring a clean build on each secondary system, and are expected to resolve the overwhelming majority of any compiler or syntax support issues on these systems. Other developers may however be consulted for assistance or advice if changes need to be made to their code, particularly if these changes are subtle. In the event of syntax support conflicts, the C++ standard takes precedence unless not supported by the project compiler in the specific instance. Compiler defects are expected to be flagged with #ifdef statements for ease of later removal. Compiler defects need to be recorded for reference by other developers, and submitted to the vendor for correction.

4. Code development tools: The project tests code development tools, such as memory leak detectors, periodically. If they work with the AIPS++system, and are useful, they are added to the list of recommended tools for use in debugging or testing. Consortium sites are not required to purchase these tools however, although passing tests with some of these tools may be part of the code review standards recommended by the QAG.

5. Code re-use: Developers are expected to re-use AIPS++ library code wherever possible, without duplicating core library capabilities.