Fortran

Sorgt für modernen Fortran-90+-Code statt veralteter F77-Muster.

Original-Beschreibung der Autoren: Modern Fortran rules for scientific computing, modules, explicit interfaces, kind parameters, memory safety, and testing

Die Regel

---
description: Modern Fortran rules for scientific computing, modules, explicit interfaces, kind parameters, memory safety, and testing
globs: ["**/*.f", "**/*.f90", "**/*.f95", "**/*.f03", "**/*.f08", "**/*.for", "**/*.ftn", "CMakeLists.txt", "*.cmake", "Makefile"]
alwaysApply: false
---

# Fortran Programming Guidelines

## Basic Principles

- Use modern Fortran standards such as Fortran 2003, 2008, or newer.
- Use `implicit none` in every program unit.
- Put procedures in modules to provide explicit interfaces.
- Keep modules focused and place each major module in its own file.
- Prefer clear, structured code over clever language tricks.
- Avoid obsolete features such as COMMON blocks, GOTO-heavy control flow, and numeric labels.

## Kinds and Types

- Define numeric kind parameters in one shared module, such as `kind_mod`.
- Use `real(kind=dp)` or the project-approved real kind for floating point values.
- Use `integer(kind=i4)` or the project-approved integer kind for integer values.
- Define constants such as pi explicitly.
- Include units in comments for physical quantities.
- Use derived types to group related data instead of passing many primitive arguments.

## Naming and Style

- Use lowercase for language keywords and most identifiers.
- Use underscores for multi-word names.
- Avoid names that differ only by case.
- Use descriptive names for procedures and state.
- Repeat the procedure or module name after `end` statements.
- Keep indentation consistent in `do`, `if`, `select case`, and module blocks.

## Procedures

- Keep subroutines and functions short and single-purpose.
- Use `intent(in)`, `intent(out)`, or `intent(inout)` for every dummy argument.
- Keep functions free of side effects whenever possible.
- Prefer early validation and clear returns over deep nesting.
- Use `use, only:` when importing from modules.

## Memory and Arrays

- Prefer allocatable arrays over pointers unless pointer semantics are required.
- Check allocation state and array sizes before use.
- Deallocate allocatable arrays when their lifetime is not naturally scoped.
- Specify array bounds clearly when they matter.
- Avoid unnecessary dynamic allocation in hot loops.

## Testing and Build

- Use CMake, fpm, Make, or the project-standard build system consistently.
- Compile with warnings enabled and treat important warnings as failures in CI.
- Add unit tests for public procedures and integration tests for numerical workflows.
- Test boundary conditions, invalid inputs, and representative scientific cases.
- Verify numerical tolerances explicitly rather than relying on exact floating point equality.

## Common Mistakes

- Do not declare variables after executable code unless using a block construct.
- Do not assume `random_number` is a function; it is a subroutine.
- Do not write to stdout from pure procedures.
- Do not declare the same variable twice in the same scope.
- Do not assume pi, dp, or project kinds already exist without importing or defining them.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Regel hilft der KI, bei Fortran-Code moderne Konventionen (Fortran 90 und neuer) statt veralteter F77-Muster vorzuschlagen: freie statt feste Formatierung, explizite Typisierung mit IMPLICIT NONE, Module statt COMMON-Blöcke und lesbare Kontrollstrukturen. Relevant ist das vor allem für wissenschaftliches Rechnen, numerische Simulationen und die Pflege gewachsener Legacy-Codebasen, wo alte und neue Syntax oft gemischt vorkommen. Der Mehrwert liegt darin, dass generierter oder überarbeiteter Code wartbarer und portabler wird, ohne bestehende performancekritische Routinen zu verändern. Für reine Neuentwicklungen in anderen Sprachen ist die Regel irrelevant; sie zahlt sich vor allem dort aus, wo Fortran aus historischen oder Performance-Gründen weiterlebt.

Praxis-Tipp

Nutzen Sie die Regel beim Refactoring alter F77-Dateien, z. B. mit „Modernisiere diese Subroutine auf Fortran 90 mit expliziter Typisierung“, statt den Code manuell Zeile für Zeile umzuschreiben.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …