Notebook Style Guide

Applies to: all course notebooks, examples, exercises, and capstone work

Purpose

A notebook is not only a place to run code. In this course, it is the learner's analysis record. A good notebook shows the question, the data, the cleaning choices, the analysis steps, the charts, and the conclusion in a way another person can rerun and understand.

Standard notebook sections

Use this order unless a module has a clear reason to change it:

1. Title and analysis question.
2. Setup and imports.
3. Data loading.
4. First inspection.
5. Data dictionary notes.
6. Cleaning and validation.
7. Analysis tables.
8. Visualization.
9. Interpretation.
10. Limitations and next steps.

Code habits

• Keep imports in the setup section.
• Use relative paths.
• Do not overwrite raw data files.
• Use clear variable names such as orders, monthly_sales, or cleaned_feedback.
• Keep one main idea per code cell.
• Add short comments only when the reason is not obvious.
• Run the notebook from top to bottom before marking it complete.
• Record package versions when the module requires exact output.

Markdown habits

• Explain the purpose before a block of code.
• Write short interpretations after important outputs.
• Use simple English.
• Do not paste large tables into markdown.
• Use headings to make the workflow easy to scan.
• Write limitations honestly.

Output habits

• Important tables need readable column names.
• Important charts need a clear title.
• Axes need labels unless the chart is self-explanatory.
• A chart must answer a question or check the data.
• Every important visual needs a short written explanation.

Final check

• [ ] The notebook has a clear question.
• [ ] The data path is relative.
• [ ] The notebook runs top to bottom.
• [ ] The raw data is not overwritten.
• [ ] Important cleaning decisions are visible.
• [ ] Important charts have titles and labels.
• [ ] The conclusion states evidence and limits.
• [ ] The notebook contains no personal data, secrets, tokens, or local absolute paths.