C2.6 Programming Practices

Style

Style Guide

• Tab size = 4 spaces
• Use VScode’s Format Document command to format the document when possible
• Put “//Spectrum 3847” at the top of every file
• If the code is based on another team’s work put “//Based on team#### code” you can add a year if you want
• Follow this style guide for coding conventions - https://medium.com/geekculture/java-coding-standards-68ba6c426794
• A lot of our code doesn’t currently fit this guide, fixing files to meet it is good practice.

Package Names

“It should be an in lowercase ASCII letter such as java, lang. If the name contains multiple words, it should be separated by dots (.) such as java.util, java. lang.”

​

Examples:

package frc.robot;

package frc.robot.commands.ballpath;”

Class and Interface name:

“It should start with the uppercase letter. Use words, instead of acronyms. “

​

It should be a noun such Robot, Climber, ShuffleboardTab, etc. Use words, instead of acronyms

​

Examples:

class Robot

class Swerve

class Launcher extends SubsystemBase

​

​

​

Method name

“Usually, the method name should either be a verb or verb-noun combination starting with the lower letter. If it contains multiple words then every inner word should start with uppercase.”

​

Examples:

public void periodic()

public void setVelocity( double velocity)

public static Command getAutonomousCommand()

​

​

Variable name:

“i) Instance variable: Usually variable name should be a noun starting with a lowercase letter. If it contains multiple words then every inner word should start with uppercase.”

Examples: motor; speed; velocityRPM;

​

“ii) Constants (final variables):- Usually, a constant name should be a noun. It should contain the only uppercase If it contains multiple words then words are separated with the ( _ ) underscore symbol. Usually, we declare constants with public static and final modifiers.”

Examples:- CAN_CONFIG_TIMEOUT, MIN_BATTERY_VOLTAGE, PIGEON_ID

​

​

​

Variable name:

“iii) boolean variables:- It uses “is” as a prefix before the variable name. Negated boolean variable names must be avoided.”

Example:- boolean isAngleEnableCurrentLimit boolean isDriveMotorInvert

Don’t Use:- boolean isNotDriveMotorInvert

​

“iv) Private variable:- It uses underscore ( _ ) at end of the variable name.”

Example:- private double rpm_; private double kP_, kI_, kD_, kF_;

​

​

​

​

Importing Classes

“ Imported classes must always be listed explicitly. Importing classes explicitly gives an excellent documentation value for the class at hand and makes the class easier to comprehend and maintain.”

​

Example:- import frc.robot.commands.ResetGyro; import frc.robot.commands.swerve.TurnToAngle;

Don’t Use:- import frc.robot.commands.*;

​

​

Method/Class Modifiers

“Modifiers should be given in the following order:

<access> static abstract synchronized <unusual> final native

The <access> modifier (if present) must be the first modifier.”

​

Examples:- public static XboxGamepad driver

Don’t Use:- static public XboxGamepad operator

​

​

Git / Github

Git VScode Integration

• Allows you to easily commit and sync changes.
• Allows you to easily switch branches in repos

Github Pull Requests and Issues Extension

• Extension Website
• Lets you add issues to code and create/approve pull requests from inside VScode

Github Desktop App

• https://desktop.github.com/
• This is a very easy to use tool to commit and sync repository changes. It may be easier to use than the integration inside of VScode for some tasks.

Git Branches

• Each programmer should create a branch of the code.
• Merge the changes from main into your branch often.
• You can also merge changes from other branches to work with code that other team members are working on.
• When using team laptop make sure you switch to your branch
• You are free to write code and test ideas in your branch of the repository.
• Commit and Sync your branch often.
• Write useful descriptions of each commit whenever possible.

Pull Requests

• To get changes from your branch into main you need to create a pull request
• Pull Request = a request for the lead programmer to pull your changes into “main” branch.
• Don’t make a pull request to “main” unless it’s working in the simulator.

​

Github Tags/Releases

• Before and after each event we should create a Tag/Release of our code on Github, this way we can easily download it and deploy to the robot if we need to.

​

• It’s good practice to make other releases as well if we have big milestones or know big changes are coming

Git Tips

• Use Push/Pull - Fetch from all Remotes to update the list of branches
• Git Cheat Sheet - https://training.github.com/downloads/github-git-cheat-sheet/

Folders

Top Level Folders

• Lib = Files that are generic and we will reuse from year to year
• Robot = files that are specific to each robot

Lib

• Drivers = classes that allow certain hardware to work or wrappers for other WPIlib hardware classes
• Gamepads = classes that allow us to better use gamepads such as button classes, filtering joystick access classes, etc.
• Math = classes that help perform math
• Sim = classes that help with simulation
• Swerve = classes that help setup and run the swerve drive
• Telemetry = classes that help with data sent from robot to driverstation, so shuffleboard, dashboard, etc
• Util = other library classes.

robot

• commands = holds all the commands for that act on subsystems
• Subfolders for each subsystem or groups of subsystems
• constants = holds classes for all our constant files
• Each subsystem has a constants file
• subsystems = holds all our subsystems for each mechanism on the robot
• telemetry = holds all the classes for shuffleboard, smartdashboard, network tables, and logging

Classes

Subsystems

• Should contain each action the subsystem/mechanism can perform
• Such as an intake being able to control it’s motor,
• Mechanism that may need to operated at different times can have subclass subsystems
• Such as the intake’s pneumatic cylinder, it would need it’s own default command.
• Should contain any sensors that are part of the subsystem/mechanism

Subsystem Creation

• Create a new file Subsystem.java
• Create the subsystem variables
• motor(s)
• solenoids(s)
• sensors(s)
• Create a constructor Subsystem()
• Instantiate all of our subsystem variables
• motor = new TalonFX(CanIDs.subsystem);
• Default Command should be added for every subsystem
• ​

Subsystem - Default Commands

• Default command should put subsystem in it’s safest state.
• Motors should all be commanded to stop or controlled by joysticks.
• Pneumatics may be commanded to a specific state if it makes sense
• Such as the intake going up when no command is controlling it.

Constants

• CanIDs and Hardware ports should go in the main constants file these don’t change often
• Each subsystem should have it’s own constants file for all of their tunable settings.

Commands

• For many subsystems a main Commands document that contains multiple static methods that return commands is likely the easiest way to create them.
• Using RunCommand, StartandEndCommand and others are easier than full Command classes.