Code organization

TeamCode

In the official FTC Android Studio project, your team's Java files belong under:

TeamCode/src/main/java/org/firstinspires/ftc/teamcode/

One working OpMode in that folder is enough to begin. You do not need separate classes for every motor on day one.

As the robot grows, group related files in packages. For example:

teamcode/
├── MainTeleOp.java       ← reads gamepads
├── PracticeAuto.java     ← runs an autonomous routine
└── mechanisms/
    └── Arm.java          ← handles the arm motor

The diagram is a possible team layout, not an extra folder structure required by the SDK. A file in mechanisms/ needs a matching package declaration, such as package org.firstinspires.ftc.teamcode.mechanisms;.

File responsibilities

The OpMode should decide when an action happens. A mechanism class can decide how to control its hardware. For example, the OpMode reads a button and asks the arm to move; the arm class owns the motor and its power limit.

Here is a small mechanism class. Save it as mechanisms/Arm.java:

package org.firstinspires.ftc.teamcode.mechanisms;

import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.HardwareMap;

public class Arm {
    private final DcMotor motor;

    public Arm(HardwareMap hardwareMap) {
        motor = hardwareMap.get(DcMotor.class, "arm_motor");
    }

    public void move(double requestedPower) {
        double safePower = Math.max(-0.25, Math.min(0.25, requestedPower));
        motor.setPower(safePower);
    }
}

Inside an OpMode in the teamcode package, import Arm, construct it before waitForStart(), then call arm.move(...) in the active loop. This is a pattern for separating jobs; it still needs the usual OpMode setup and a matching arm_motor configuration.

When to split files

Move code into a new method or class when you can give it a clear name and use it without copying the same logic. Examples:

• A stopDrive() method makes a safety action easy to find.
• An Arm class can keep arm limits together when several OpModes use the arm.
• A RobotConfig class can hold shared, measured constants such as encoder counts per revolution.

Keep season-specific scoring decisions in the autonomous or match logic, so a reusable motor helper does not silently depend on one game.

Review

Can a new teammate find the code that controls a motor in under a minute? Can they see where its configuration name and power limit live? If yes, the structure is doing its job. Build after moving files; package and import mistakes show up immediately.

Next steps

Use naming conventions to make the files readable and comments to explain decisions that names cannot show.