Getting your code and scripts submission-ready is about making them reproducible, readable, and easy for reviewers (and future readers) to run. Start by cleaning up your project: remove commented-out dead code, hard-coded absolute paths, and any personal configuration files. Then, organize everything into a clear folder structure — typically src/ for source code, data/ for inputs (even if just a sample), results/ for outputs, and docs/ for instructions. Add a README that explains what the code does, the exact environment it needs, and a quick-start example.
Next, lock down your environment. Create a requirements.txt (Python) or environment.yml (conda), or use a container like Docker if your workflow is complex. Pin exact package versions — not just “numpy” but “numpy==1.26.0” — so reviewers can replicate your environment precisely. If you used any non-standard hardware or proprietary libraries, note those explicitly. For R users, a renv.lock file serves the same purpose.
Write a minimal, end-to-end test script that runs from a clean clone and produces a small output — this is your “sanity check.” If you have data that cannot be shared due to size or privacy, include a synthetic sample and clearly document how to obtain the full dataset. Also, set a fixed random seed if your code involves stochastic processes; this makes results reproducible and lets reviewers verify your figures.
Finally, add a short LICENSE file (even a simple MIT or CC0) and ensure all file names are descriptive and consistent. If your journal has specific software requirements (e.g., a statement about code availability), check the author guidelines early — many journals now ask for a “Code Availability” section in your paper. When you write that section, mention the repository link (GitHub, Zenodo, etc.) and the exact commit hash or version tag you used for the submission.
If you’re juggling dozens of references while writing the manuscript, WisPaper’s TrueCite can help verify that your citations — especially those pointing to software papers or methods — are real and correctly formatted, saving you from a last-minute scramble. Once everything is in place, run your test script one final time on a fresh machine or virtual environment to confirm it works, then zip the folder and submit with confidence.
