developers:coding_rules
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
developers:coding_rules [2021/08/31 20:31] – [9. Use of BLAS and LAPACK subroutines] Xavier Gonze | developers:coding_rules [2021/08/31 20:32] – [12. Other topics] Xavier Gonze | ||
---|---|---|---|
Line 672: | Line 672: | ||
(at present, no other BLAS routines than those called by LAPACK are used in ABINIT, so these rules are indications for the future) | (at present, no other BLAS routines than those called by LAPACK are used in ABINIT, so these rules are indications for the future) | ||
- | ====== Modules ====== | + | ====== |
MG: This section should be rewritten from scratch! | MG: This section should be rewritten from scratch! | ||
Line 695: | Line 695: | ||
Be cautious when you introduce such a feature, and mention it to the ABINIT coordinator. | Be cautious when you introduce such a feature, and mention it to the ABINIT coordinator. | ||
- | ====== Derived datatypes ====== | + | ====== |
- | Derived datatypes should be declared in the adequate module (MG: And this rule is not followed in many places, e.g dataset_type, | + | 12.a. Derived datatypes should be declared in the adequate module (MG: And this rule is not followed in many places, e.g dataset_type, |
These are powerful F90 constructs, but the information about them is not local to the subroutine | These are powerful F90 constructs, but the information about them is not local to the subroutine | ||
where they are used, so they should be introduced in a controlled way, in order for the programmers to become sufficiently easily familiarized with them: the introduction of a new derived datatype must be made in agreement with the coordinator of ABINIT. | where they are used, so they should be introduced in a controlled way, in order for the programmers to become sufficiently easily familiarized with them: the introduction of a new derived datatype must be made in agreement with the coordinator of ABINIT. | ||
The introduction of appropriate derived datatypes in ABINIT is one of the central issues of v3.2 and later versions. | The introduction of appropriate derived datatypes in ABINIT is one of the central issues of v3.2 and later versions. | ||
- | 11.b. Suffix a type identifier with ' | + | 12.b. Suffix a type identifier with ' |
TYPE ipe_type | TYPE ipe_type | ||
Line 713: | Line 713: | ||
| | ||
- | 11.c. Pros and cons. | + | 12.c. Pros and cons. |
Grouping connected variables into structured types is interesting for readability (it avoids too long | Grouping connected variables into structured types is interesting for readability (it avoids too long | ||
Line 723: | Line 723: | ||
However, source code itself may become less readable. Also, remember that the use of structured types is never more efficient for CPU: complex declarations should be avoided. | However, source code itself may become less readable. Also, remember that the use of structured types is never more efficient for CPU: complex declarations should be avoided. | ||
- | ====== | + | ====== |
For the time being, pointers are only allowed when an array has to be allocated in a subprogram, and | For the time being, pointers are only allowed when an array has to be allocated in a subprogram, and |
developers/coding_rules.txt · Last modified: 2021/08/31 20:35 by Xavier Gonze