Styleguide: Difference between revisions
Jump to navigation
Jump to search
m (hat „BlueM Code-Formatierung“ nach „BlueM.Sim Code-Formatierung“ verschoben) |
No edit summary |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== | ==General== | ||
[[Bild:Fortran_tabstops.jpg|thumb|Visual Studio 2005 | * '''Line-endings:''' all line-endings should be Windows line-endings (CR-LF), git needs to be set to not change this: <code>git config --global core.autocrlf true</code><ref>https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration</ref> | ||
* | * '''Encoding:''' for historical reasons, all source files should be encoded in ISO-8859-1 | ||
* | |||
* | ==Fortran== | ||
[[Bild:Fortran_tabstops.jpg|thumb|Visual Studio 2005 Fortran tabstop settings]] | |||
* Indenting: three-character indents, tabs saved as spaces | |||
* Keywords (e.g. <code>IF</code>, <code>FUNCTION</code>, <code>INTEGER</code> etc.) should be capitalized. | |||
* The keywords <code>END IF</code>, <code>END DO</code> etc. should be written with a space as shown here. | |||
<br clear="all"/> | <br clear="all"/> | ||
== | ===Operators=== | ||
The modern form of operator syntax should be preferred (e.g. <code>>=</code> rather than <code>.GE.</code>). A lot of code currently still uses the old format, though. | |||
{| class="wikitable" | |||
! Description !! Old syntax !! New syntax | |||
|- | |||
| Less than || <code>.LT.</code> || <code><</code> | |||
|- | |||
| Less than or equal to || <code>.LE.</code> || <code><=</code> | |||
|- | |||
| Equal to || <code>.EQ.</code> || <code>==</code> | |||
|- | |||
| Not equal to || <code>.NE.</code> || <code>/=</code> | |||
|- | |||
| Greater than || <code>.GT.</code> || <code>></code> | |||
|- | |||
| Greater than or equal to || <code>.GE.</code> || <code>>=</code> | |||
|} | |||
== | ===General formatting=== | ||
'''NOTE:''' There is still some debate about how code should be formatted. We might look into using an autoformatter such as [https://github.com/pseewald/fprettify fprettify] in the future. | |||
Funktionen sollten folgendermaßen formatiert werden: | Funktionen sollten folgendermaßen formatiert werden: | ||
* Vorschlag A | * Vorschlag A | ||
<fortran> | <source lang="fortran"> | ||
CXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | CXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | ||
Line 44: | Line 64: | ||
cxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | cxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | ||
</ | </source> | ||
* Vorschlag B | * Vorschlag B | ||
<fortran> | <source lang="fortran"> | ||
C---------------------------------------------------------------------- | C---------------------------------------------------------------------- | ||
Line 92: | Line 112: | ||
end module MOD_Beispiel | end module MOD_Beispiel | ||
</ | </source> | ||
==References== | |||
<references/> | |||
[[Kategorie:BlueM | [[Kategorie:BlueM.Sim Development]] | ||
Latest revision as of 02:21, 25 August 2022
General
- Line-endings: all line-endings should be Windows line-endings (CR-LF), git needs to be set to not change this:
git config --global core.autocrlf true
[1] - Encoding: for historical reasons, all source files should be encoded in ISO-8859-1
Fortran
- Indenting: three-character indents, tabs saved as spaces
- Keywords (e.g.
IF
,FUNCTION
,INTEGER
etc.) should be capitalized. - The keywords
END IF
,END DO
etc. should be written with a space as shown here.
Operators
The modern form of operator syntax should be preferred (e.g. >=
rather than .GE.
). A lot of code currently still uses the old format, though.
Description | Old syntax | New syntax |
---|---|---|
Less than | .LT. |
<
|
Less than or equal to | .LE. |
<=
|
Equal to | .EQ. |
==
|
Not equal to | .NE. |
/=
|
Greater than | .GT. |
>
|
Greater than or equal to | .GE. |
>=
|
General formatting
NOTE: There is still some debate about how code should be formatted. We might look into using an autoformatter such as fprettify in the future.
Funktionen sollten folgendermaßen formatiert werden:
- Vorschlag A
CXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX c Funktionsbeschreibung FUNCTION FOO (BAR) RESULT (LOK) c ................................................................. USE MODULE INTEGER i LOGICAL LOK character(*) str c ................................................................. LOK = .FALSE. c Kommentar DO i = 1, 10 CALL FOOBAR() IF (.NOT. LOK) GOTO 9999 END DO LOK = .TRUE. GOTO 10000 c ................................................................. c Fehlerbehandlung 9999 IF (.NOT. LOK) ERROR = FEHLER(50, ' ', ' ', 0) GOTO 10000 c ................................................................. 10000 RETURN END FUNCTION FOO cxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Vorschlag B
C---------------------------------------------------------------------- C MOD_Beispiel: Ein Modul ! c Anmerkung: blabla C---------------------------------------------------------------------- module MOD_Beispiel use MODULE_BLABLAblabla implicit none integer MemberInt contains C---------------------------------------------------------------------- C funktion FOO : Eine unsinnige zu Demonstrationszwecken erstellte virtuelle Fkt c Anmerkung: gibt false zurück wenn Fehler ! C---------------------------------------------------------------------- logical function FOO (BAR) use MODULE_BLABLA integer i logical LOK character(*) str FOO = .FALSE. !--------------------------------------------- !Abschnitt A !--------------------------------------------- do i = 1, 10 CALL FOOBAR() !Wenn fehler dann raus ! IF (.NOT. LOK) ERROR = FEHLER(50, ' ', ' ', 0) return end if end do FOO = .TRUE. return end function FOO end module MOD_Beispiel