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

Formatting

Practices to maintain readability in a team's codebase

Consistent formatting makes code easier to review, debug, and hand over to the next programmer. Agree on a small set of conventions as a team and apply them consistently.

Formatter

Use the formatter configured by your Android Studio or project. If the project does not include one, use Android Studio's Reformat Code action and keep the default or Kotlin style. Avoid manually reformatting unrelated files in a code review.

Naming

  • Use UpperCamelCase for Java classes and interfaces, such as DriveSubsystem.
  • Use lowerCamelCase for methods and variables, such as setTargetPosition.
  • Use clear names for hardware configuration strings. They must match the configuration exactly.
  • Use constants for values that explain robot behavior, such as MAX_DRIVE_POWER or ARM_HOME_TICKS.
  • Avoid names that encode a temporary assumption, such as motor2 or magicNumber.

Methods and comments

  • Keep methods focused on one task and split long routines into named steps.
  • Comment on intent, units, and non-obvious constraints. Prefer // Distance in millimeters over a comment that only repeats the code.
  • Remove commented-out code and update comments when behavior changes.
  • Keep telemetry useful to the driver and debugging team; remove noisy per-loop output before competition.

Safety and review

  • Check direction, limits, and behavior with the robot safely supported before field testing.
  • Review changes as a team and test the affected behavior on the actual robot. A clean build does not prove the robot is safe or tuned.
  • Keep -specific names, scoring rules, and field assumptions out of reusable code unless they are clearly labeled and checked against the current game manual.

Check the official FTC programming resources for tool-specific behavior and the current game manual for season rules.

Sources

  • FIRST Tech Challenge programming resources
  • game manual

Loop timing and bulk reads

Measure the control loop, refresh cached inputs, and reduce hardware traffic before adding threads

Comments and documentation

Explain decisions that code alone cannot show

On this page

FormatterNamingMethods and commentsSafety and reviewSources