Code Review

Code Review

This rubric sets a common standard for reviewing Science Centre code. Its purpose is to make code easier to share, understand, and reuse.

Reviews should focus on five areas:

• Code Formatting – Consistency in style, naming, and readability.
• Project Structure – Organized files and folders that follow shared conventions.
• Functional Correctness – Code runs without errors and produces valid results.
• Efficiency – Scales appropriately and avoids unnecessary work.
• Intelligibility – Clear, documented, and easy to understand.

See the table below for full details.

Note

The full, up-to-date rubric is available here

Section	Standard	Meets	Needs Improvement	Not Met	Comments
Code Formatting	Styled according to a standard guide (e.g., tidyverse style guide)
	Consistent indentation, spacing, and line length (e.g., 80-character limit)
	Variable and function names are concise, descriptive, and consistently named
	Code is free of commented-out, unused, or duplicate lines
	Functions and code blocks are ordered logically, with consistent structure across files
Project Structure	File names follow a consistent naming convention (e.g., snake_case, camelCase, kebab-case)
	File names describe their purpose and use numeric prefixes (e.g., 01_clean_data.R)
	Data is organized in 0_data/ with clear subfolders such as external/ and processed/
	Code is stored in 1_code/, grouped by language if needed (e.g., r_scripts/, python_scripts/)
	Intermediate/temporary files stored in 2_pipeline/
	Outputs are in 3_output/ and organized into subfolders (e.g., figures/, models/, tables/, maps/)
	Manuscripts and reports are stored in 4_writing/
	Includes a README.md explaining structure, setup, and dependencies
	Repository visibility follows ABMI policy (Repository visibility follows ABMI policy (private during development, public when appropriate)
Functional Correctness	Inputs are validated for type, length, and missing values
	Edge cases handled appropriately (e.g., nulls, empty, extreme values)
	Environment and dependencies are reproducible and documented
	Code runs without runtime errors
	Logic is sound and does what’s intended
	Outputs validated against expected results
	Outputs are logically correct given the inputs
	Logging and error handling support debugging and provide informative messages
Efficiency	Avoids redundant computations
	Uses appropriate data structures for the task
	Code scales with larger datasets without significant performance issues
	Uses parallel processing when appropriate
	Uses batch processing when appropriate
	Reuses existing code or functions instead of duplicating code
Intelligibility	Code has a commented header with Title, Author, Date, Inputs, Outputs, and Notes
	Code is easy to read and understand
	Code is modular, with each part serving a clear, single purpose
	Includes comments that explain why, not just what
	Documentation (README, headers, inline comments) is complete and helpful
	Code is located in the appropriate file, folder, or package
	Overall flow of the code is logical and easy to follow, with descriptive, numbered section headers