View Single Post
  #7   Spotlight this post!  
Unread 25-03-2012, 21:28
daniel_dsouza daniel_dsouza is offline
does what needs to be done.
FRC #2449 (Out of Orbit Robotics)
Team Role: Alumni
 
Join Date: May 2011
Rookie Year: 2011
Location: Chandler, AZ
Posts: 231
daniel_dsouza has a spectacular aura aboutdaniel_dsouza has a spectacular aura about
Re: How does your team architect its codebase?

Our team likes dividing our code into classes based upon the functional units of our robot. This year featured a drivetrain, a elevator, a shooter, a bridge lowering device, a control, a (sketch) motion sensor, a constants, and output class and a main class for interfacing logic.

Each class only interfaces in the main class, in order to make bugs easier to debug. This allows our code to be extremely clean, as variables and methods not needed by the main are declared private and hidden in that class.

Having multiple classes also allows us to use Object Orientated Programming, so we could (if we every needed to) create a "new" drivetrain for use in auto or teleop.

The last great thing I can think of at the moment is that we can multitask effectively, especially if each programmer writes one class. Close to the end of build season (when we had an entire robot), all of us (programmers) gather together to write out the main class, taking into account decisions on strategies, and workarounds that the mechanical team needed us to fix in code. Our SVN server deserves a mention somewhere around here.

One thing you would want to be careful about is the overuse of global variables. They certainly have their place, but when you have global variables pointing to global variables, things have gone too far...