🆕 Software · Best Practices

Code Style & Autoformatting

Consistent style makes debugging faster and teammates more effective. One keyboard shortcut handles most of it automatically.

Keyboard shortcut: Shift+Alt+F (Windows/Linux) or Shift+Option+F (Mac) autoformats the current file instantly. Run before every commit.

The Core Style Rules for VRC C++

Avoid
void intakefwd(){ intake.move(127);if(x>5) {doSomething();}}
Prefer
void intakeForward() { intake.move(127); if (x > 5) { doSomething(); } }

Naming Conventions

Comment Rules

// GOOD: Explains WHY, not what (the code already shows what) // 300ms timer prevents false positives during motor startup current spike const int STALL_TIME_MS = 300; // BAD: Restates the code — adds no information // Set stall time to 300 const int STALL_TIME_MS = 300; // GOOD: Section headers for navigation within long files // ── Drive Control ─────────────────────────────────────────────────── // GOOD: Tuning note with date and context // Tuned 2025-01-15: reduced kP from 5.0 to 4.2 — was overshooting 3 inches

VS Code Autoformat Setup

Shift+Alt+FFormat current file (Windows/Linux)
Shift+⌥+FFormat current file (Mac)
Ctrl+Shift+POpen Command Palette → type "Format Document"
🖼️
[Image Placeholder: VS Code before/after autoformat — messy indentation on left, clean formatting on right after Shift+Alt+F]

To enable format on save (recommended for team projects): open VS Code Settings, search for editor.formatOnSave, and enable it. Now every file is formatted automatically when you save — no manual step needed.

Add a .clang-format file to your project root to enforce consistent brace and indentation style across all team members' VS Code setups. A minimal one: create .clang-format with content BasedOnStyle: Google. This applies Google’s C++ style guide, which is clean and well-suited to PROS projects.
ℹ️
Style is notebook evidence too. Screenshots of well-organized, consistently styled code with meaningful comments demonstrate software engineering discipline. Judges who look at code excerpts in engineering notebooks can tell the difference between a team that treats code as craft vs one that treats it as a necessary evil.
⚙ STEM Highlight Technology: Readability, Maintainability & Technical Debt
Code style is not cosmetic — it is information design. Research in software engineering consistently shows that code is read 10× more often than it is written. Naming is the primary documentation: armTargetPosition communicates intent; x does not. Technical debt is the accumulated cost of messy code: when you need to change something quickly at a competition, unreadable code costs time you do not have. Auto-formatting (Shift+Alt+F) enforces a consistent grammar — just as academic writing follows style guides, code follows formatting conventions.
🎤 Interview line: “We treat code style as engineering discipline. Consistent naming and formatting reduce cognitive load when debugging under pressure at a competition. We use .clang-format to enforce rules automatically — the same approach used in every professional software development environment.”
✅ Code Style Checklist — Before Every Commit
Run Shift+Alt+F (Windows) or Shift+Option+F (Mac) to autoformat
Do this every time before committing or uploading
All function names use camelCase
intakeForward(), not IntakeForward() or intake_forward()
All constants use ALL_CAPS_WITH_UNDERSCORES
MAX_DRIVE_SPEED not maxDriveSpeed
Every function has a one-line comment above it
// Runs intake forward at full speed
No TODO or debug comments left in competition code
Clean them up before the competition build
.clang-format file is in the root of the project
Ensure all teammates get the same formatting rules
No lines over 100 characters wide
Wrap long lines for readability

Common Style Mistakes

Inconsistent indentation — mixing tabs and spaces causes IntelliSense to misread scope. Always use spaces (Shift+Alt+F fixes this automatically).
Cryptic variable namesx, val, temp in production code make debugging impossible for teammates and coaches.
Magic numbersintake.move(127) tells you nothing. intake.move(MAX_INTAKE_SPEED) is self-documenting and easy to change globally.
The teammate test: if a teammate has never seen your code, can they understand what each function does in under 30 seconds? If not, rename or add a comment.
▶ Next Step

Style enforced. Now split your code across files so it stays organized as the robot scales.

📄 Organizing Code Across Files →
🔬 Check for Understanding
Why is chassis.pid_drive_set(intakeTriggerDistance, driveSpeed) better than chassis.pid_drive_set(d, s)?
It runs faster because named variables are cached
Single-letter variable names are reserved for math equations only
The descriptive names document intent — you can read the code without needing a comment to explain what d and s mean
There is no difference — compilers treat all variable names identically
Related Guides
📄 Organizing Code →🏷 Naming Guide →💾 Version Control →
📝
← ALL GUIDES