Skip to content
CrocoDocs
Starter GuideProgrammingEngineeringDesignPortfolio
Documentation

Introduction

IntroductionBIOBUZZ game overview

Getting started

Getting startedBlocksOnBot JavaAndroid StudioYour first OpModeJava basicsMotors and servosNonblocking codeDebugging robot code

Control systems

Control systemsJoystick mappingField-centric mecanum drivePID controlFeedforwardFlywheel velocity controlSystem identificationMotion profilingKalman filterLow-pass filter

Autonomous

AutonomousTimed and encoder movementOdometryLocalization troubleshootingMotion planningReliable autonomous sequencesPure PursuitSensor fusionAuto to TeleOp handoff

Season topics

Season topicsProjectile mathematicsTurret aimingShooting on the move

Code practices

Code practicesNaming conventionsCode organizationLoop timing and bulk readsFormattingComments and documentationTeam collaboration

Libraries

LibrariesNextFTCFTCLibSolversLibPedro PathingRoad RunnerFTC DashboardMercurial v2Mercurial v1PanelsSloth

Community software

Community softwareBlaze FTCOpenLoopHive Vision

Sensors and vision

Vision overviewVision basicsLimelight 3A
Starter Guide
Engineering
Design
Portfolio
Appearance

Naming conventions

Pick names that tell a teammate what each part of the code means

Descriptive names

Compare motor1 with leftDriveMotor. The second name tells a teammate where the is and what it does. Clear names reduce the number of comments needed to understand an .

Use the same words throughout the project. If the team calls a an “arm,” avoid switching between arm, lift, and elevator unless they are different things.

Java and Kotlin conventions

What you namePatternExample
Class or interfaceUpperCamelCaseArmController
Variable or methodlowerCamelCasetargetAngleDegrees, moveArm()
ConstantUPPER_SNAKE_CASEMAX_ARM_POWER
PackageLowercase wordsorg.firstinspires.ftc.teamcode.arm

These patterns match normal style and work well for Kotlin too. Consistency matters more than inventing a special name for every case.

Measurement units

targetPosition leaves an important question: is it degrees, ticks, or millimeters? A name such as targetAngleDegrees or targetTicks answers it.

double targetAngleDegrees = 45.0;
int armEncoderTicks = armMotor.getCurrentPosition();
double maxArmPower = 0.25;

These lines are illustrative values inside a larger OpMode. They do not convert ticks to degrees; that conversion needs a measured encoder scale and a known zero position.

Hardware names

The name passed to hardwareMap.get is a string from the active . It is not automatically created by your Java or Kotlin variable name:

DcMotor leftDriveMotor = hardwareMap.get(DcMotor.class, "left_drive");
val leftDriveMotor = hardwareMap.get(DcMotor::class.java, "left_drive")

Here, leftDriveMotor is a code variable and left_drive is the configured device name. The latter must match exactly, including capitalization.

Naming checklist

Before committing, ask a teammate to read one method without your explanation. If a name makes them ask “which motor?” or “what unit?”, improve that name. Do not rename a configured hardware string without also updating the configuration.

Next steps

See code organization for where to put these clearly named parts as the project grows.

Code practices

Write robot code that your teammates can read, test, and improve

Code organization

Keep an FTC project easy to navigate as the robot grows

On this page

Descriptive namesJava and Kotlin conventionsMeasurement unitsHardware namesNaming checklistNext steps