View Single Post
  #12   Spotlight this post!  
Unread 29-05-2010, 14:45
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: writing reusable code / preparing for the future

Quote:
Originally Posted by davidthefat View Post
...I never really comment my code and its going to take people quite a while to even understand what something does
1. Comments make good programming practice. I have gotten used to them in LabVIEW, and I can't see any reason to not at least describe what a function does in C/C++

2. If they cant understand what it does, then it is either too complex or not implemented "well".

Example: If I have a VI that processes the lookup of kicker pullback for kick distance, I name it "kicker_lookup_distance.vi" (similar to how you would name a function "lookup_distance" and put it in namespace "kicker".) Within the VI, it is written in two portions: lookup range (0-1) and scale that to the correct voltage. I have a comment describing what each does, the variables defining vMax and vMin are global constants, and comments describing the process for determining the pullback, etc.
If someone were to look at this VI, knowing that it's name was "kicker_lookup_distance", they would be able to tell what it does and what its purpose is. All of my code is written in this way, with things like state machines in seperate VI's from PID processing, gain scheduling, etc. and seperate VI's for more complex states (e.g. those that don't feed a position directly to the PID control). Each is well commented and a decent programmer should be able to figure out what it does between the comments, VI connector names, and VI (function) names.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack