rseng-code-quality

Solid

Covers writing readable research code and structuring software projects: naming, formatting, style guides, linters and formatters, pre-commit hooks, modular design, and a conventional directory layout with top-level metadata files. Use when the user asks how to make code readable or clean, pick or enforce a style guide, set up linting/formatting or pre-commit, name variables and functions, organise a repo, or decide where files and data go. For generating a new project from a maintained template see rseng-project-scaffolding; for quantitative complexity and duplication measurement see rseng-software-metrics; for architecture-level structure see rseng-software-design.

Code & Development 14 stars 2 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
39
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Readable code and project structure Use this skill when writing or reviewing research code for readability, or when laying out a project's directories. Both goals serve the same end: code is read far more often than it is written (a commonly cited read/write ratio is 7:1), so anything that helps a future reader - including the original author months later - directly improves reusability, the "R" in the FAIR research software principles. Favour conventions others already recognise over clever, project-specific inventions. ## Make code readable Apply these rules when authoring or reviewing code: - Use descriptive names for variables, functions, classes, and modules that explain their purpose. Avoid single-letter names outside tight loops or well-known math notation. - Format consistently: consistent indentation and spacing throughout. Consistency within a project or module matters more than any global ideal - when joining existing code, adopt the conventions already in place rather than imposing your own. - Separate code into sections with blank lines (between classes, functions, logical blocks) so structure is visible at a glance. - Keep lines short. Prefer many short lines over few long ones - blocks that are horizontally short and vertically long are easier to scan. - Use indentation to show hierarchy and mark the beginning and end of control structures. - Add type annotations (type hints) for untyped or dynamically typed languages such as Python or J...

Details

Author
fdiblen
Repository
fdiblen/rseng-agent-skills
Created
4 days ago
Last Updated
4 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

rseng-code-review

Covers reviewing existing code and whole projects, not just new diffs: structured codebase audits that produce ranked findings and then implement the agreed improvements, recurring project reviews after major tasks and milestones, review scoping by risk and tier, and turning review findings into tracked work and lessons. Use PROACTIVELY after major tasks and milestones, and when the user asks for a code review, codebase audit or health check of existing code, wants improvements suggested and applied, mentions reviewing the project after a milestone or before a release or submission, or when inherited or long-unreviewed code needs a structured pass. For diff-time pre-review of new work see rseng-pair-programming; for PR-time review process and rules see rseng-version-control-review.

14 Updated 4 days ago
fdiblen
Data & Documents Solid

rseng-documentation

Covers how to document research software at every level: writing a README, code-level docs (comments, docstrings, API and CLI help), project docs (INSTALL, CONTRIBUTING, LICENSE, CITATION, changelog), publishing hosted documentation with Read the Docs, and capturing a Research Software Story. Use when the user asks how to write or improve a README, decide what documentation their project needs, add docstrings or inline comments, document an API or CLI, set up Sphinx/MkDocs/Doxygen, host docs on Read the Docs, structure a docs site, or write the narrative context and history behind a project. For outward-facing papers, talks and announcements see rseng-science-communication; for public and citizen-science narrative see rseng-storytelling.

14 Updated 4 days ago
fdiblen
AI & Automation Solid

rseng-fair-software

Covers how to apply the FAIR principles - findable, accessible, interoperable, reusable - to research software, and how to assess a project's FAIRness. Use when the user asks how to make software FAIR, wants help with findability, discoverability, or software reuse, mentions metadata, persistent identifiers, DOIs, registries, or software citation in a FAIR context, or asks to run a FAIR self-assessment or checklist on a repository. (Automated FAIR4RS scoring, compliance levels and CI gates with the FAIRGuard tool are rseng-fairguard; FAIR for ML models and datasets is rseng-fair-ml; finding existing software to reuse is rseng-software-reuse.)

14 Updated 4 days ago
fdiblen