Reproducibility + organization + code style

All written work should be reproducible, and the GitHub repo should be neatly organized.

• Points for reproducibility + organization will be based on the reproducibility of the entire repository and the organization of the project GitHub repo.
• The repo should be neatly organized as described above, there should be no extraneous files, all text in the README should be easily readable.

Evaluation criteria

Reproducibility + organization

Category	Less developed projects	Typical projects
Reproducibility (code)	Required files are missing. Quarto files do not render successfully (except for if a package needs to be installed).	All required files are provided. Project files (e.g. Quarto, Shiny apps, R scripts) render without issues and reproduce the necessary outputs.
Reproducibility (packages)	renv.lock file does not include all required packages. External users have to manually install packages in order to get code to evaluate.	renv.lock includes all required packages. Manual package installation is not required to render any code in the repo (e.g. Quarto documents, R scripts).
Data documentation	Codebook is missing. No local copies of data files.	All datasets are stored in a data folder, a codebook is provided, and a local copy of the data file is used in the code where needed.
File organization/readability	Documents lack a clear structure. There are extraneous materials in the repo and/or files are not clearly organized.	Documents (Quarto files and R scripts) are well structured and easy to follow. No extraneous materials.

Code style

Category	Less developed projects	Typical projects
Naming conventions	Variable names, functions, and data objects use inconsistent or unclear naming (e.g., df1, temp).	Variable names, functions, and data objects use clear, descriptive naming that reflects their purpose (e.g., sales_by_region, salesByRegion, etc.)
Formatting and spacing	Code lacks consistent indentation, spacing around operators, or appropriate line breaks. Multiple statements appear on single lines.	Code follows {tidyverse} formatting conventions with consistent indentation, spaces around operators, line breaks for long pipelines.
Use of base pipe	Pipes are absent, misused, or create overly long/deeply nested workflows that are difficult to understand.	Pipes (|>) create clear, linear data transformation workflows. Pipelines are reasonably sized and intermediate steps are understandable.
Deprecated functions	Uses deprecated or superseded functions in their code. Fails to adhere to warnings about deprecated code and update their syntax to use the correct implementation.	Does not utilize deprecated or superseded functions. No warnings or messages produced noting code uses deprecated functions.
Code cleanliness	Code contains unused variables, commented-out blocks, duplicated code, or unnecessary intermediate objects. Repeated logic is copy-pasted rather than factored out.	No redundant or dead code present. Where applicable, repeated logic is factored into short, focused, clearly-named functions rather than copy-pasted.
Comments	Comments restate what code does rather than explaining why. Comments are excessive, outdated, or missing where needed.	Comments explain why a step exists rather than what it does. Comments are used sparingly and are up to date with the code.
Avoidance of code smells	Code contains magic numbers, overly complex expressions, hard-coded paths, or deeply nested conditionals that reduce readability and flexibility.	Code avoids magic numbers, overly complex expressions, hard-coded paths, and deeply nested conditionals.