Language-specific research software practice
The process skills in this pack are language-agnostic; this skill answers
language-SPECIFIC questions with per-language guidance. Each language
guide follows the same template -
introduction, information sources, setup, development environments,
style standards, packaging, testing, quality assurance, optimization,
logging, documentation, dependencies, starting points - so comparable
answers exist for every covered language.
Current-tool quick reference per language
The strongest current stack per ecosystem (the pack-wide rule: best
current option, runner-up named, reason given - and these move, so
verify against the ecosystem when in doubt):
- Python: uv for environments/packaging (runner-up: pip+venv - uv is
faster and lockfile-native), ruff as the single linter+formatter
(replaces flake8/isort/black), pytest for tests, mypy for types,
pyproject.toml as the one config home. Python 2 relics (2to3, six)
and legacy tool chains belong to migration work, not new projects.
- R: usethis/devtools for package workflow, testthat for tests,
lintr + styler for quality, roxygen2 for docs, renv for
reproducible libraries; rOpenSci's guide is the community bar.
- C/C++: CMake as the build lingua franca, Catch2 or GoogleTest for
tests, clang-tidy + clang-format for quality, sanitizers
(ASan/UBSan) in CI, a package manager (vcpkg/Conan) over vendored
sources.
- Fortran: fpm (Fortran Package Manager) for new projects, gfortran
in CI, pFUnit for tests; modern-Fortran style over F77 habits, and
interop via iso_c_binding when Python needs to call it.
- Julia: built-in Pkg with Project.toml/Manifest.toml, Test stdlib,
JuliaFormatter; register in General only once the API settles.
- JavaScript/TypeScript: TypeScript by default for anything shared,
vitest for tests, Biome as linter+formatter (runner-up:
eslint+prettier - Biome is one fast tool), npm lockfiles committed.
- Bash: shellcheck non-negotiable, bats-core for tests when a script
earns them - and past ~100 lines, prefer a real language
(rseng-software-design's honesty about scripts).
These map the pack's practices INTO each ecosystem; the process
itself (testing discipline, packaging, CI shape) stays in the
process skills.
How to use the guides
- Identify the language, open the matching page from references.md, and
answer from its sections rather than from generic memory - the guides
encode current, community-reviewed tool choices (for example the
Python guide's Ruff-first style tooling, pytest, mypy/Pydantic typing
and Sphinx/MkDocs documentation stack).
- For multi-language projects, apply each language's guide to its part
and keep shared concerns (CI, licensing, citation) with the process
skills.
- Where a language guide and a general skill overlap (testing,
packaging, documentation), the general skill gives the WHY and the
language guide gives the concrete WHAT for that ecosystem.
- The covered languages: Python, R, JavaScript/TypeScript, C/C++,
Fortran, Rust, Bash - plus a technology overview page for adjacent
topics.
Choosing a language
For "which language should this project use", combine the guides'
starting-point sections with rseng-management-planning (technology
choice): weigh ecosystem fit for the research domain, team experience,
and long-term maintainability over micro-benchmarks.
Working with this skill
The generated references.md beside this file lists the source material
and pointers:
- references.md - verified Learn more pointers
Learn more (verified):
Related skills
Check whether any of these applies before moving on:
- rseng-code-quality - linter and formatter per ecosystem
- rseng-dependency-management - verifying current ecosystem tooling
- rseng-management-planning - language choice for new projects
- rseng-notebooks - Python/Julia notebook practice
- rseng-project-scaffolding - language templates at kickoff
- rseng-testing - per-language test framework choice
1---2name: rseng-language-guides3description: Covers language-specific research software practice: per-language conventions for Python, R, JavaScript/TypeScript, C/C++, Fortran, Rust and Bash - setup, development environments, style standards, packaging, testing, quality assurance, optimization, logging, documentation and dependency management. Use when the user asks which tools or conventions to use FOR A SPECIFIC LANGUAGE in research software (e.g. Python packaging, R style, C++ QA, Fortran tooling, Rust starting points, shell scripting practice), or wants a language-by-language comparison.4license: CC-BY-4.05---67# Language-specific research software practice89The process skills in this pack are language-agnostic; this skill answers10language-SPECIFIC questions with per-language guidance. Each language11guide follows the same template -12introduction, information sources, setup, development environments,13style standards, packaging, testing, quality assurance, optimization,14logging, documentation, dependencies, starting points - so comparable15answers exist for every covered language.1617## Current-tool quick reference per language1819The strongest current stack per ecosystem (the pack-wide rule: best20current option, runner-up named, reason given - and these move, so21verify against the ecosystem when in doubt):2223- Python: uv for environments/packaging (runner-up: pip+venv - uv is24 faster and lockfile-native), ruff as the single linter+formatter25 (replaces flake8/isort/black), pytest for tests, mypy for types,26 pyproject.toml as the one config home. Python 2 relics (2to3, six)27 and legacy tool chains belong to migration work, not new projects.28- R: usethis/devtools for package workflow, testthat for tests,29 lintr + styler for quality, roxygen2 for docs, renv for30 reproducible libraries; rOpenSci's guide is the community bar.31- C/C++: CMake as the build lingua franca, Catch2 or GoogleTest for32 tests, clang-tidy + clang-format for quality, sanitizers33 (ASan/UBSan) in CI, a package manager (vcpkg/Conan) over vendored34 sources.35- Fortran: fpm (Fortran Package Manager) for new projects, gfortran36 in CI, pFUnit for tests; modern-Fortran style over F77 habits, and37 interop via iso_c_binding when Python needs to call it.38- Julia: built-in Pkg with Project.toml/Manifest.toml, Test stdlib,39 JuliaFormatter; register in General only once the API settles.40- JavaScript/TypeScript: TypeScript by default for anything shared,41 vitest for tests, Biome as linter+formatter (runner-up:42 eslint+prettier - Biome is one fast tool), npm lockfiles committed.43- Bash: shellcheck non-negotiable, bats-core for tests when a script44 earns them - and past ~100 lines, prefer a real language45 (rseng-software-design's honesty about scripts).4647These map the pack's practices INTO each ecosystem; the process48itself (testing discipline, packaging, CI shape) stays in the49process skills.5051## How to use the guides5253- Identify the language, open the matching page from references.md, and54 answer from its sections rather than from generic memory - the guides55 encode current, community-reviewed tool choices (for example the56 Python guide's Ruff-first style tooling, pytest, mypy/Pydantic typing57 and Sphinx/MkDocs documentation stack).58- For multi-language projects, apply each language's guide to its part59 and keep shared concerns (CI, licensing, citation) with the process60 skills.61- Where a language guide and a general skill overlap (testing,62 packaging, documentation), the general skill gives the WHY and the63 language guide gives the concrete WHAT for that ecosystem.64- The covered languages: Python, R, JavaScript/TypeScript, C/C++,65 Fortran, Rust, Bash - plus a technology overview page for adjacent66 topics.6768## Choosing a language6970For "which language should this project use", combine the guides'71starting-point sections with rseng-management-planning (technology72choice): weigh ecosystem fit for the research domain, team experience,73and long-term maintainability over micro-benchmarks.7475## Working with this skill7677The generated references.md beside this file lists the source material78and pointers:7980- references.md - verified Learn more pointers818283Learn more (verified):84 - https://peps.python.org/pep-0008/ - PEP 8 style guide for Python code85 - https://style.tidyverse.org - Tidyverse style guide for R86 - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines -87 C++ Core Guidelines88 - https://doc.rust-lang.org/book/ - The Rust Programming Language book89 - https://fortran-lang.org/learn/ - Fortran-lang community90 learning resources9192<!-- related-skills:begin -->9394## Related skills9596Check whether any of these applies before moving on:9798- rseng-code-quality - linter and formatter per ecosystem99- rseng-dependency-management - verifying current ecosystem tooling100- rseng-management-planning - language choice for new projects101- rseng-notebooks - Python/Julia notebook practice102- rseng-project-scaffolding - language templates at kickoff103- rseng-testing - per-language test framework choice104105<!-- related-skills:end -->
fdiblen