Chief Delphi - Programming Organization

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Programming Organization (http://www.chiefdelphi.com/forums/showthread.php?t=40587)

Re: Programming Organization

Quote:

Originally Posted by Rickertsen2

Document the code well. Maintain change logs.

Both are excellent ideas, and will save you a ton of grief when things don't work right.

I personally document every line of code, and usually my code has more comments than code. Comments should be sufficient for anyone moderately familiar with code to understand completetly and fully what a line is supposed to be doing.

Cange logs are harder to enforce, but literally writing down every change (was Foo == bar, changed to foo==bar, DAR 11/23/05) with who did it and when can be extraordinarily useful when something that was working suddenly stops. Reviewing it later is also an excellent learning tool, you see how things evolved and learn ways to get there sooner next time. (Note that some CV systems do this for you)

This is how professional programmers are supposed to do it. Sadly, it's not always the case, but projects that do are often more successful. Learn it the right way, the discipline will serve you well for a lifetime.

Don

Re: Programming Organization

Quote:

Originally Posted by Dave Scheck

Please not that C compilers are not required to support the double slash style comment.

For a C compiler to be compliant with the ISO/ANSI C99 standard, it must accept the // style comments. These were not in the earlier C89 standard although most mainsteam compilers accepted them as an extension. The problem is the demand for pure C has dropped in favor of C++ and the bulk of users are probably now in the embedded market. So many of the compilers there haven't been updated to be compliant with the new standard, probably to lower sales volumes. Although recognizing the // style comment should be child's play to a compiler writer whom you're going to entrust with optimizing your source into machine code.

Re: Programming Organization

Everything said so far is good. Here is my list of the important stuff:

Use a standard formatting style. This includes how to position braces ({ and }), spacing between arguments, amount of indent (2 spaces, 4 spaces, or a tab), line overflow, etc. I believe the de facto standard of C is like this:

Code:

// You should use more descriptive names for everything

void AFunctionName(int an_argument, int other_argument)

{

        int retval = DoSomething(other_argument, an_argument + 1);

        int n = 0;

        for (int i = 0; i < retval; i++)

        {

                // So, do something here...

                n = an_argument * i;

        }

}

Use a versioning system. CVS and Subversion are the best (only) free ones I've heard of. Do some googling as to how to use them/set them up. If used appropriately, this can also cover changelogs. (Write a descriptive commit message! I prefer many commits with specific changes to few large commits that can't have a good description.)

Document. I find doxygen works well for API-type documentation (Which functions do what, and what arguments they take). For logic documentation, nothing beats good ol' comments.

Create functions for conceptual reasons. A function should perform a specific task, and that task should be fairly clear from the name. (And having clearly named functions with unambiguous purposes also helps with self-documenting code, if you believe in such a thing.)

I agree entirely with teaching basic OOP concepts, since that includes ideas of abstraction and encapsulation (not to mention a few other things), concepts I consider important to writing clear code that works.

Code reuse. Last year, I used a system much like the autonomous scripting to handle motor control (control loops). This was a great boon for me, because when part of the robot didn't work, I could say, "It's not the code. The same code works on the other joint." (This is greatly undervalued. Definately going to do something similar again.)

Many files are good. You should actually reduce the number of functions in user_routines.c and user_routines_fast.c. Have a file devouted to translating human input, another one for driving, and several for autonomous. (I consider autonomous a 95-10 situation: 95% of your work goes into 10% of the match.)

In 2004 (code) and in 2005, I organized code based on function on the robot. All the hardware interaction went through abstraction macros/functions. This ment higher-level code would do things like:

Code:

 //user_routines.c, line 175

 //Map Joysticks to drive train

 Drive_Joystick(OI_Left, OI_Right);

While code farther in would be doing:

Code:

// Drive.c, line 51

void Drive_Joystick(char Left, char Right)

{

        if(Left > 127)

        {

                Left_CIM = Left_Drill =  (128 + JOYSTICK_SMOOTHING[Left - 127]);

        }

        else

        {

                Left_CIM = Left_Drill = (127 - JOYSTICK_SMOOTHING[127 - Left]);

    }

    

//        Right_CIM = Right_Drill = Right;

           if(Right > 127)

        {

                Right_CIM = Right_Drill =  (128 + JOYSTICK_SMOOTHING[Right - 127]);

        }

        else

        {

                Right_CIM = Right_Drill = (127 - JOYSTICK_SMOOTHING[127 - Right]);

    }

}

(These same routines were used for autonomous, as well.)
This is a simplistic sample. The Hand_*() functions in Grabber.c (which maybe should have been broken up) are the most complex, due to the current-limiting sensor. BTW, this example is not from the year I used doxygen, so the functions themselves are poorly documented. *_Check() functions compared the input value to the current value and reacted appropriately (except the drive code, which just mapped input to output without feedback).

Re: Programming Organization

If you are intent upon using Subversion (like someone I know is.) and you want to use Eclipse (which I do) then I would suggest using an Eclipse plug-in called Subclipse. It's made by the same people that make Subversion. It's not as nice as Eclipse's CVS integration but it's more than adequate for FIRST purposes. Also, more information on Eclipse (e.g. installation instructions, setting up a basic project, etc) along with an updated version of my plug-in can be found in this white paper.
The white paper itself is not very useful if you are already familiar with Eclipse, but otherwise it should be helpful.

Re: Programming Organization

Quote:

Originally Posted by coastertux

How would I set up a SVN/Subversion?

A brief description of many free version control system is at http://producingoss.com/html-chunk/vc-systems.html (I just happened to stumble across that by chance when reading something else and figured you or others might be interested).

For how to setup a repository see http://subversion.tigris.org/faq.html#repository (how to make Eclipse use it has already been mentioned).

Re: Programming Organization

We are using CVS now as I could not find a free SVN server.