Naming Conventions & Reserved Words

// Section 01

Why Naming Conventions Matter

Code is read far more often than it is written. Every name you choose is a message to your future self and your teammates.

💡

The Golden Rule: a name should tell you what something is or what something does — without needing a comment to explain it. armPosition is self-documenting. x is not.

What Goes Wrong With Bad Names

Hard to read

int x = 0;
int y = 0;
bool f = false;
void a() {
  if (f) {
    x = 200;
  }
}

Self-documenting

int armTargetDeg = 0;
int clawSpeed = 0;
bool intakeRunning = false;
void raiseArm() {
  if (intakeRunning) {
    armTargetDeg = 200;
  }
}

Both blocks do exactly the same thing. But six months from now — or the night before a competition — only the second one tells you what it does at a glance.

Real Costs of Poor Naming on a VRC Team

A teammate cannot add a new mechanism without breaking existing code because they cannot tell what variables do.
Debugging takes 3x longer because you cannot read the code quickly under pressure.
You introduce a bug while "fixing" a variable that you misunderstood.
Judges ask about your code and you cannot explain it — because even you have forgotten what val2 does.

✅

Team standard: agree on one naming style before the season starts and use it consistently across all files. Consistency matters more than which specific style you pick.

1 / 4

// Section 02

The Four Naming Styles

C++ and PROS/EZ Template use specific conventions depending on whether something is a variable, function, constant, or type. Knowing which style to use where is part of writing professional code.

camelCase

Local variables, parameters, member variables

✓ intakeSpeed armTargetDeg isRunning

✗ IntakeSpeed arm_target_deg IS_RUNNING

PascalCase

Functions, classes, custom types

✓ RaiseArm() DriveForward() ClawControl

✗ raiseArm() drive_forward() clawcontrol

SCREAMING_SNAKE

Constants — values that never change

✓ MAX_DRIVE_SPEED WHEEL_DIAMETER PORT_LEFT_FRONT

✗ maxDriveSpeed wheelDiameter

snake_case

EZ Template style — used in chassis config and PROS built-ins

✓ drive_distance turn_to_angle set_pid

Note: EZ Template uses this — match it in related code

Quick Reference Rules

// VARIABLES — camelCase int armTargetDeg = 0; bool intakeRunning = false; double driveSpeedMultiplier = 1.0; // CONSTANTS — SCREAMING_SNAKE_CASE const int MAX_DRIVE_SPEED = 127; const double WHEEL_DIAMETER_IN = 3.25; const int PORT_LEFT_FRONT = 1; // FUNCTIONS — PascalCase (team preference) or camelCase void RaiseArm(int targetDeg) { ... } void RunIntake(bool forward) { ... } // EZ TEMPLATE built-ins — snake_case (match their style) chassis.drive_distance(24); chassis.turn_to_angle(90);

Length Guidelines

Too short: x, v, f — meaningless outside a 2-line context. Allowed only in simple loop counters like i, j.
Too long: leftFrontMotorCurrentSpeedForAutonomous — exhausting to type and read. Aim for 2–3 meaningful words.
Just right: armTargetDeg, intakeSpeed, driveLeftVoltage — specific enough to understand, short enough to write.

⚠️

Avoid abbreviations that are not universally understood. armSpd saves 3 keystrokes and costs 10 seconds of confusion every time someone reads it. Write armSpeed.

2 / 4

// Section 03

VRC-Specific Naming Examples

Real examples from a competition robot codebase — ports, mechanisms, autonomous routines, and EZ Template config.

Port Definitions — Use Constants, Never Magic Numbers

A "magic number" is a raw number with no explanation. Motor arm(5) tells you nothing. If the arm motor moves to port 7, you have to hunt for every 5 in the code. Use named constants instead.

// ❌ Magic numbers — don't do this pros::Motor arm(5); pros::Motor intake(8); // ✅ Named port constants — change port in ONE place const int PORT_ARM = 5; const int PORT_INTAKE = 8; const int PORT_LEFT_FRONT = 1; const int PORT_LEFT_BACK = 2; const int PORT_RIGHT_FRONT = -3; // negative = reversed const int PORT_RIGHT_BACK = -4; pros::Motor arm(PORT_ARM); pros::Motor intake(PORT_INTAKE);

Mechanism State Variables

// Toggle states — use descriptive bool names bool intakeForward = true; // direction toggle bool clawOpen = false; // claw state bool armAutoMode = false; // auto vs manual arm // Arm position targets — use CONSTANTS not raw numbers const int ARM_SCORE_HIGH = 1800; const int ARM_SCORE_LOW = 900; const int ARM_INTAKE_POS = 100; const int ARM_STOWED = 0; // Use the constant — not the raw number arm.move_absolute(ARM_SCORE_HIGH, 200);

Autonomous Routine Naming

// Autonomous function names — be specific about strategy // ❌ Vague — what does "auton1" do? void auton1() { ... } void auto_test() { ... } // ✅ Clear — anyone reading the selector knows what to pick void AutonomousBlueLeft() { ... } void AutonomousRedRight() { ... } void AutonomousSafeRoute() { ... } // low-risk fallback void AutonomousSkills() { ... } // programming skills // EZ Template selector registration ez::as::auton_selector.autons_add({ {"Blue Left — 14pts", AutonomousBlueLeft}, {"Red Right — 14pts", AutonomousRedRight}, {"Safe Route — 8pts", AutonomousSafeRoute}, });

ℹ️

Auton selector display names — the string that shows on the Brain screen — should include the alliance color, side, and expected point value. This prevents the driver from selecting the wrong routine in a stressful match environment.

3 / 4

// Section 04

Reserved Words

These words are already claimed — by C++, PROS, or EZ Template. If you try to use them as variable or function names, your code will either fail to compile or behave in confusing ways.

⚠️

You cannot use reserved words as names. Trying to name a variable int or a function while is a compile error. Naming something chassis when EZ Template already defines it will cause a conflict. This list covers the most common ones you will encounter.

C++ Reserved Keywords

These are built into the C++ language itself. The compiler will always reject them as identifier names.

int

Integer type

double

Floating-point type

float

Single-precision float

bool

Boolean true/false

char

Single character

void

No return value

true / false

Boolean literals

if / else

Branching

while

Loop

for

Counted loop

return

Exit function

break

Exit loop/switch

continue

Skip loop iteration

const

Immutable value

class

Object type

struct

Data structure

new / delete

Memory management

nullptr

Null pointer value

switch / case

Multi-branch select

default

Switch fallthrough

namespace

Scope grouping

using

Namespace alias

include

Preprocessor directive

define

Preprocessor macro

PROS API Names to Avoid Shadowing

These are not reserved keywords but are defined by PROS. Using the same name for your own variable creates a conflict or hides the PROS version.

pros::Motor

Motor object type

pros::Imu

Inertial sensor type

pros::Controller

Controller type

pros::Task

Parallel task type

pros::delay

Sleep/wait function

initialize

PROS startup hook

autonomous

Auton period hook

opcontrol

Driver control hook

disabled

Disabled period hook

competition_init

Competition init hook

E_CONTROLLER_MASTER

Controller enum

MOTOR_GEAR_GREEN

Gear cartridge enum

EZ Template Names to Avoid Shadowing

EZ Template defines these globally or within the ez namespace. Creating your own variable with the same name will cause unexpected behavior.

chassis

EZ drive object

ez::Drive

Chassis class type

ez::as

Auton selector namespace

ez::Auton

Auton registration struct

default_constants

PID defaults function

drive_distance

Linear drive method

turn_to_angle

Turn method

set_drive_pid

Drive PID setter

opcontrol_tank

Tank drive method

opcontrol_arcade

Arcade drive method

💡

VS Code will warn you. If IntelliSense underlines a variable name in red or yellow, hover over it to read the error message. A redefined name or a conflict with a reserved word will appear here before you even compile. Treat IntelliSense warnings as errors — fix them immediately.

⚙ STEM Highlight Computer Science: Namespaces, Scope & Symbol Resolution

Variable names in C++ live in scopes — a name declared inside a function is local (hidden outside it); a name declared at file scope is visible throughout that file; a name in a namespace requires the namespace prefix to access. Reserved words (like pros::E_MOTOR_BRAKE_HOLD) are symbols that already exist in a linked library — redefining them creates an ambiguous symbol that the compiler cannot resolve. Naming conventions (camelCase, PascalCase, SCREAMING_SNAKE) encode type information visually — a form of Hungarian notation that helps humans and IDEs simultaneously.

🎤 Interview line: “We follow camelCase for variables and PascalCase for types to encode type information visually — when you see armMotor you immediately know it is an instance, not a class. This is a lightweight form of type annotation that works without formal documentation.”

🔬 Check for Understanding

Why does naming a variable delay in a PROS project cause problems even if it compiles?

It doesn’t — variable names can never conflict with function names

delay is a reserved C keyword and cannot be used at all

It shadows the pros::delay() function in that scope, potentially causing calls to your variable instead of the PROS function, leading to a type error or unexpected behavior

PROS uses delay as a macro that gets text-substituted everywhere

4 / 4

Variables & Reserved Words

What Goes Wrong With Bad Names

Real Costs of Poor Naming on a VRC Team

Quick Reference Rules

Length Guidelines

Port Definitions — Use Constants, Never Magic Numbers

Mechanism State Variables

Autonomous Routine Naming

C++ Reserved Keywords

PROS API Names to Avoid Shadowing

EZ Template Names to Avoid Shadowing