![]() |
Rewrote Robot Code: Opinions/Thoughts?
I've decided to sharpen my skills and rewrite our robot code without reference to the old one (reason for TODO:'s on the autonomous choices), I'd like to know if I'm doing anything inefficient or if there's just a better way to do things. Thanks!
Code:
package org.usfirst.frc.team6077.robot; |
Re: Rewrote Robot Code: Opinions/Thoughts?
A couple of comments:
1) Many motor controllers have an input directly on the motor controller for limit switches. You obviously can do this in code still, but just wanted to point it out. 2) You should look into command based programming. While it's "overkill" for your project - if you're hoping to take your programming to the next level in FRC, the command based programming allows you to set up various commands/subsystems that can then be reused in groups of commands. I personally am a big fan of thinking of programming commands into the robot vs programming a button that turn X motor. https://wpilib.screenstepslive.com/s...ed-programming 3) I would absolutely break up your for loop into two separate ones. With what you have right now, if you only had 2 automodes you'd get an index out of bounds mode. And really, the number of drive motors you have shouldnt change. Just code those four lines out rather than have a for loop for it. Nothing other than the max function use jumps out as a particularly bad practices to me. I would prefer renaming the dm# to leftFront, leftBack, rightFront, rightBack, and a more useful description for ds#. You might consider having something to the driver station to report if you're limited your drivetrain speed or not. |
Re: Rewrote Robot Code: Opinions/Thoughts?
A lot of these recommendations are based on the assumption that people will want to read your code (that includes you, two weeks or so after you finish this project and stop looking at the code).
Code:
private String[] autoArray = { autoChoice1, autoChoice2, autoChoice3, autoChoice4, autoChoice5, autoChoice6 };Code:
private String[] autonomousChoices = {There's no need to publish arm speeds in the Robot constructor - you won't know them at that point, plus the robot is disabled. Instead, publish them in the teleop loop. Instead of using magic numbers like "ds1 = new DoubleSolenoid(0, 1)", use a RobotMap file to store the numbers. That makes it easier to read. Right now it's not easy to figure out what 0 and 1 mean in the context. Instead, you can have nice code like "sampleTextSolenoid = new DoubleSolenoid(RobotMap.SAMPLE_TEXT_HARDWARE_DOWN, RobotMap.SAMPLE_TEXT_HARDWARE_UP)" where it's clear what the numbers mean. Change some functions a bit. "closeOpenCam" might be better as "reinitializeCameraStream(Camera setActive, Camera setInactive)" "rumbleABit" can be refactored as "rumbleFor(double seconds)" Finally: This isn't code golf!! As @ahartnet said, separate the logic for drive motors and auto modes. When writing code like this, always go for readability and not shortest length possible. |
Re: Rewrote Robot Code: Opinions/Thoughts?
In reference to euhlmann's statement about your declaration of drive motors:
Quote:
Imagine this scenario: Code:
Object driveMotor;The point is, when you declare a new variable, its type is all the rest of your code has to go by. Thus, you should be as specific as possible when declaring its type (by this I mean the lowest in the tree. In Java, every class extends Object. If a class has subclasses, unless for some reason the type isn't supposed to be known, you should declare it as one of those subclasses). Amended: Code:
VictorSP driveMotor; |
| All times are GMT -5. The time now is 08:19 AM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi