fortran — Cursor rule: what it does, how to install
A Cursor rule for modern Fortran practices covering modules, types, arrays, builds, and tests. Use it when working on scientific Fortran code.
.cursor/rules/fortran.mdcWhat fortran does
This rule guides Cursor toward Fortran 2003, 2008, or newer. It asks for implicit none, explicit interfaces through modules, shared kind parameters, descriptive names, and structured control flow. Legacy patterns such as COMMON blocks, numeric labels, and GOTO-heavy code are discouraged.
Procedures should declare intent(in), intent(out), or intent(inout) for every dummy argument, while module imports should use use, only:. The guidance favors allocatable arrays, checks allocation state and dimensions, and avoids needless allocation inside hot loops. It also covers tests for public procedures, invalid input, boundary cases, numerical tolerances, and builds with CMake, fpm, or Make.
The rule targets Fortran source files plus CMakeLists.txt, *.cmake, and Makefile. Its alwaysApply value is false, so files outside those glob patterns will not receive it automatically.
What it helps with
- organize Fortran code with focused modules
- define shared numeric kind parameters
- check procedure intents and explicit interfaces
- prevent unsafe allocatable-array usage
- test numerical boundary cases
Example prompts for the agent
- Rewrite this procedure in modern Fortran and add explicit
intentdeclarations for its arguments. - Review
solver.f90for type, array, and module-import problems. - Add tests for invalid inputs and boundary conditions, then check numerical tolerances in the
CMakeLists.txtbuild.
How to install fortran
Manually: put the files in place
.cursor/rules/fortran.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/fortran.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/fortran.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/fortran.mdManually: put the files in place
.clinerules/fortran.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about fortran
How do I install fortran in Cursor?
Save the rule in the project file .cursor/rules/fortran.mdc.
What does the fortran rule do?
It guides Cursor on modern Fortran modules, explicit interfaces, kind parameters, memory handling, testing, and build configuration.
Which files does the fortran rule target?
It targets .f, .f90, .f95, .f03, .f08, .for, and .ftn files, plus CMakeLists.txt, *.cmake, and Makefile.
Source text
fortran.mdc · CC0-1.0
--- 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.
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules