It is true that globally-scoped subsystems make it a bit more annoying to unit-test your code. A team that naively tries to encapsulate their subsystems within robot.java without a solid understanding of what they’re doing is going to find it very difficult to write working command-based code.
#Wpi screensteps drivebase how to#
You have to explain how, in this specific case, globally-scoped subsystems are a bad idea, and then explain how to use the framework if you change this. You cannot simply justify them by mentioning, in an abstract sense, how globally-scoped fields are undesirable in an OO language. The changes you make cannot simply be made in isolation.
#Wpi screensteps drivebase code#
What you do in your video, however, is worse than both - you instantiate your subsystems as private nonstatic fields of Robot.java, but then fail to mention the (substantial!) ways the rest of the code has to change to accommodate this. The best way to address this is to inject your subsystems into your commands, and write your commands so that your subsystems are hidden behind interfaces - but for a team that’s just starting out (which is the situation in which one is most-likely to use the given templates), this is a fair bit of overhead for seemingly-nebulous gains. Where the subsystems-as-global-variables design really hamstrings you is in code re-use commands written in the “standard” command-based style are rigidly-coupled to the subsystems they use, and thus can rarely be used again on future robots. If you don’t intend to re-use any of your robot code, you’re not really going to get burned by having global (or singleton, if you want to be a *bit *fancier) subsystems. That subsystems are declared as global variables is a valid gripe in certain contexts, but not really for the reasons you state. This isn’t a real strike against the testability of command-based, and it certainly doesn’t indicate that “the author didn’t even consider testing to be an important element.” Our team has never used the supported test mode for testing anyway, because it’s rather clunky and we’ve always found it easier to just modify our ordinary teleop or autonomous code. The lack of “test” mode being set up for you is really, really minor. However, I think many of your specific criticisms are off-base, or at the very least not adequately articulated. The documentation provided by ScreenSteps to match the template is inadequate, and suffers from many of the same problems. It doesn’t do a good job of outlining the underlying design of the framework, nor does it give any indication that there is a fair amount of flexibility in its use. As mentor for a team that makes heavy use of the command-based framework (and one who also does not particularly care for the “standard” implementation thereof), I guess I’ll respond.įor starters, I agree that the template is not very good.