Coding standards for internal tools

These are our house rules for small internal tools. They keep code readable, consistent and easy for the next person to pick up.

Naming

• Use clear, descriptive names: responseTimeframe, not rt.
• Be consistent — pick one style for names and stick to it.
• Name a function for what it does: calculatePriority().

Structure

• Keep it in a logical order: get input → process → produce output.
• Break repeated work into a small function rather than copying lines.
• Use a loop to handle a list instead of repeating yourself.

Comments

• Add a short comment above any logic that isn’t obvious — especially business rules (e.g. how priority is decided).
• Don’t comment the obvious; comment the why.

Input handling

• Don’t assume input is perfectly formatted. Allow for different cases (e.g. “High” or “high”).
• Check for missing or unexpected values and handle them sensibly.

Approved features and libraries

• Use standard language features: variables, strings, numbers, conditionals, loops and simple functions.
• Don’t add external libraries unless they’re on the approved list — check with the IT Coordinator first.

Readability

• One idea per line; keep lines reasonably short.
• Format consistently (indentation, spacing).
• If you can’t read it back easily, simplify it.

Before you hand it over

• It meets the specification.
• It passes every test case.
• It’s commented and tidy.
• You’ve written a short handover note (see the templates).