Difference between revisions of "Programming/Style"
m |
m |
||
| Line 1: | Line 1: | ||
== Programming Standards == | == Programming Standards == | ||
| − | This page will lay out the basic programming style set by the Viper HPC Team | + | This page will lay out the basic programming style set by the Viper HPC Team. |
| + | |||
| + | Software production should be: | ||
| + | |||
| + | * Maintainability | ||
| + | * Dependability | ||
| + | * Efficiency | ||
| + | * Usability | ||
| + | |||
===Life Cycle=== | ===Life Cycle=== | ||
| Line 10: | Line 18: | ||
===Requirements=== | ===Requirements=== | ||
| + | |||
| + | This is basically the requirements of the final production software, it is what you require from the process to the production stage. | ||
===Architecture=== | ===Architecture=== | ||
| + | |||
| + | Software architecture is concerned with deciding what has to be done, and which program component is going to do it (how something is done is left to the detailed design phase, below). This is particularly important when a software system contains more than one program since it effectively defines the interface between these various programs. It should include some consideration of any user interfaces. | ||
===Design=== | ===Design=== | ||
| Line 28: | Line 40: | ||
===Code Units=== | ===Code Units=== | ||
| + | |||
| + | The code that a programmer writes should be simple. This can be implemented by using: | ||
| + | |||
| + | * Subroutines that describe primitive actions (e.g. calculateMean() ). | ||
| + | * Complex logic should be avoided. | ||
| + | * Commenting of non-trivial areas. | ||
| + | |||
| + | Complicated logic for achieving a simple thing should be kept to a minimum since the code might be modified by another programmer in the future. | ||
===Portability=== | ===Portability=== | ||
| + | |||
| + | The software should be capable of being compiled or interpreted on a number of different systems, not just Viper's architecture. If this cannot be achieved (i.e. some reliance of a certain architecture) then the program should be configurable to allow different systems to be used easily. | ||
==Code development== | ==Code development== | ||
| − | ==Code building== | + | |
| + | ===Code building=== | ||
A best practice for building code involves daily builds and testing, or better still continuous integration, or even continuous delivery. | A best practice for building code involves daily builds and testing, or better still continuous integration, or even continuous delivery. | ||
| Line 43: | Line 66: | ||
===Debugging=== | ===Debugging=== | ||
| − | Programmers tend to write the complete code and then begin debugging and checking for errors. Though this approach can save time in smaller projects, bigger and complex ones tend to have too many variables and functions that need attention. Therefore, it is good to debug every module once you are done and not the entire program. This saves time in the long run so that one does not end up wasting a lot of time on figuring out what is wrong. Unit tests for individual modules, and/or functional tests for | + | Programmers tend to write the complete code and then begin debugging and checking for errors. Though this approach can save time in smaller projects, bigger and complex ones tend to have too many variables and functions that need attention. Therefore, it is good to debug every module once you are done and not the entire program. This saves time in the long run so that one does not end up wasting a lot of time on figuring out what is wrong. Unit tests for individual modules, and/or functional tests for services and applications, can help with this. |
===Deployment=== | ===Deployment=== | ||
| + | |||
Revision as of 16:01, 31 July 2017
Programming Standards
This page will lay out the basic programming style set by the Viper HPC Team.
Software production should be:
- Maintainability
- Dependability
- Efficiency
- Usability
Life Cycle
As with all types of design there are several phases of production from inception to production (and then maintenance through software updates).
Common methodologies include waterfall, prototyping, iterative and incremental development, spiral development, agile software development, rapid application development, and extreme programming.
Requirements
This is basically the requirements of the final production software, it is what you require from the process to the production stage.
Architecture
Software architecture is concerned with deciding what has to be done, and which program component is going to do it (how something is done is left to the detailed design phase, below). This is particularly important when a software system contains more than one program since it effectively defines the interface between these various programs. It should include some consideration of any user interfaces.
Design
Easily the most important stage within the full life cycle and decisions made at this stage will have ramifications for the whole software. The main purpose of design is to fill in the details within the architectural design.
Choice of programming language(s)
Viper provides a large amount of different programming languages and can be extended to include software not included within this WIKI.
Coding Standards
Commenting
Naming Conventions
Code Units
The code that a programmer writes should be simple. This can be implemented by using:
- Subroutines that describe primitive actions (e.g. calculateMean() ).
- Complex logic should be avoided.
- Commenting of non-trivial areas.
Complicated logic for achieving a simple thing should be kept to a minimum since the code might be modified by another programmer in the future.
Portability
The software should be capable of being compiled or interpreted on a number of different systems, not just Viper's architecture. If this cannot be achieved (i.e. some reliance of a certain architecture) then the program should be configurable to allow different systems to be used easily.
Code development
Code building
A best practice for building code involves daily builds and testing, or better still continuous integration, or even continuous delivery.
Testing
Testing is an integral part of software development that needs to be planned. It is also important that testing is done proactively; meaning that test cases are planned before coding starts, and test cases are developed while the application is being designed and coded.
Debugging
Programmers tend to write the complete code and then begin debugging and checking for errors. Though this approach can save time in smaller projects, bigger and complex ones tend to have too many variables and functions that need attention. Therefore, it is good to debug every module once you are done and not the entire program. This saves time in the long run so that one does not end up wasting a lot of time on figuring out what is wrong. Unit tests for individual modules, and/or functional tests for services and applications, can help with this.
Deployment
Further Information
|