Reducing code complexity

[SoftwareBug2.0]

Originally Posted by Ziv

SoftwareBug2.0 makes some good suggestions, but I think they treat the symptoms rather than the root cause.

In many FRC games, the primary challenge when programming the robot is code organization. (Occasionally an especially challenging problem like vision tracking pops up, but even then there are enough tutorials around that the algorithm itself is not the obstacle.) I suggest using the command-subsystem style from the beginning of a project. It seems like overkill at the beginning when code is simple. However, the separation between the robot subsystems, higher-level commands, and operator interface it provides makes situations like those you complain about occur less frequently, if at all. It also makes the program far easier to change in the time pressure of competition.

My earlier suggestions were indeed fixing only superficial problems, and you probably want to do more than just what I pointed out. I'll get to some suggestions about that in a second.

But first let me say that I disagree about what the primary problem is in organizing robot code. It is understanding the underlying system and its limitations. You have to discover the flaws in the underlying system, and know how to work around them. For example, there was a time years ago, when you couldn't call atan2() because it would take so long that you'd cause the watchdog timer to go off. So then we had to implement lookup tables. Similarly, my team has hit several WPIlib bugs this year. And we discovered that the amount of bandwidth that was supposed to be available to each robot really wasn't.

Now on to some higher-level code suggestions: apalrd is on the right track. You don't need to use seperate classes and functions for everything, but you there are several different layers that make sense to use.

Here are three possible layers:
1) Reading buttons
2) Generating goals for each of the subsystems
3) Running each of the subsystems

(In autonomous mode, layers 1-2 would be replaced but 3 would be unchanged)

This year, my team actually used the command based stuff, and I can't recommend it with a straight face. You can kind of get towards a problem some call "callback hell".

I understand there are some differences in opinion once you get toward style stuff, but here's an example of how I like to see code. This controls a 30-pt climber, which sadly had some mechanical issues and didn't make it onto our robot.

enum Climber_state{...};
Climber_state climber(Climber_state,bool limit_l_bot,bool limit_l_top,bool limit_r_bot,bool limit_r_top,bool climb_button){
	... //stuff with no side-effects
}
struct Climber_output{
	int left,right;
};
Climber_output get_outputs(Climber_state){
	... //pure function, no side effects
}
void write_climber_motors(Climber_output){
	... //actually poke the motors
}

A little bit about the mechanism: There are two sets of slides, each of which is controlled by a motor, and each of which has a limit switch at the top and bottom.

Going back to concrete, lower level suggestions, about the quickest change to improve the code would be to just start your function with a bunch of lines of the form:

bool cheesy_mode_button=xbox.isReleased(JStick.XBOX_A);

There are a few places where the same code reading the inputs is repeated. Whenever that happens, alarm bells should be going off in your head.