The "Right" way to program

I am the my team’s programmer who just finshed my first year of programming. When I program, i do a bunch of trial runs until my program works. I know this isn’t the “right” way to program, but i guess it worked. What would you consider to be the “right” way to program.

I would have to say working with somebody who also knows how to program helps. If you do something have them go through and check your work and do the same for them. If I had done this before Buckeye regional this year, a whole lot of chaos thursday would have been avoided. Trial runs work as long as you check the whole thing even if you change something small. I had used a variable twice for two different things in one of the earliest versions of our code and only checked the parts separately so when both parts ran the next week it freaked out. Learning from your mistakes also helps alot =)

[09 was my first year programming as well.]]

Whatever works RIGHT for you is the right way to program. That being said, clean concise code is always nice but don’t over do it. Yea there are probably a ton of tricks you could do that would make your code execute slightly faster but make it impossible to debug. You want a happy balance between the two.

Figure out what is needed, this can sometimes be the hardest part. View things from the end user’s needs, talk to domain experts. These are your drivers, your builders, game experts, etc. Remember, you are making something they will use and you must support their needs.

Write down 4 or 5 features you are going to develop, code them to completion all the while testing out code as you write it (this is what you are currently doing), then test the completed system.

The entire time, keep your 4-5 features in front of you to make sure you are not missing your goal. Stay focused. Avoid feature creep.

If your features are too big to easily develop, break them down into smaller features. Still too big, break them down further. A process known as reiterative decomposition.

This basic strategy has served me well for the last 30 years of developing software. Especially once I figured out to view my solutions from the end user’s perspective rather than from a developer’s perspective.

I echo everything [rsisk] said. In addition, I’ll point out that robotics programming is different from desktop application development. It’s impossible to model the real world completely accurately; you might be able to get a close estimate, but no matter the amount of premeditation, you’ll always have “bugs” in your program. I find my robotics code always has a considerable number of “magic numbers” that I came to by trial and error. So don’t worry about it too much if you do a lot of guessing and checking. And as was said, you’ll get better at guessing as you gain experience.

Good luck,

I completely agree with rsisk and Ryan. The sad reality of robotics is that the programmer ends up having the least say in how the robot works. Basically, if they driver doesn’t like something, you change it until they do. If it’s technically and/or mathematically “correct”, and the driver doesn’t like it, too bad. Good example: this year, we used swerve drive on our robot. Instead of doing the usual way to control it and using trig (using the vectors from one joystick to do point-and-shoot), he wanted one joystick to control the wheel angle and the other joystick to control the wheel speed, thus isolating the two values and making a couple of vector math things a bit more complicated. But the technical “correctness” of the code doesn’t win the game.

Also, yes, there is a very large discrepancy between the virtual world and the real world. Theoretically, on a differential drive (tank drive) robot, the left and right sides should have the same maximum speed. Well, not exactly. Different chain tensions, different bolt tightnesses, whatever it is, one side will almost invariably be slightly faster than the other. Last year, we ended up putting a slight turn in our code during autonomous so the robot would run straight. That’s one of those things that you try until it works.

Basically, the “correct” way to program is the way that makes the program work the way the user wants it to. Even if your supervisor comes up behind you and says, “That’s a shoddy way to do it,” if it works, it’s right. It’s worth learning the generally-accepted way, because you’ll probably learn something, but if it works now and you’re on a deadline, don’t change it.

This was my first year programming as well. I am so glad that I had not only people to teach me, but another new programmer learning along beside me. (The fact that none of us had used LabVIEW before added a few kinks into it all, too.) We all put in many hours working out our code. Now that Atlanta’s over, I can definitely see improvements that can be made for our next events.

Trial and error is certainly one way to program the robot. I know that we did this quite often. It may not be too efficient, but hey, if it’s what works best for you, then carry on.

When I programmed the robot this year, my process went like this.

First, the team decided what they wanted the robot to do. It was a very specific process, by the time we were done we had a list of all the features our robot would have, roughly sorted by priority. This is what the robot would do and nothing else.

While the design and mechanical teams were doing their thing, I would give input on the feasibility of programming a particular feature of the robot, whether I could use these sensors to control that thing to do this, etc. Of course, sometimes they have to do it a certain way, and I’ll just have to work with it. Once the teams had finalized what the final devices were going to be for the feature(of course this might change and usually does), I would begin programming it.

The first thing I do when programming a feature is to think really hard about how I would do it. I’m talking like pacing around the shop deep in thought hard. The advantage of this is that I can catch problems before I even start coding. I usually go through multiple ways of doing it, and finding all the disadvantages and potential bugs. Once I have a good idea of how I’m going to do it, then I start to code. I test individual pieces as they are completed, like sensor reading, processing, and the like. LabVIEW is really great for this part, because I can run it on the cRIO and still get the front panel values.

The first time through it almost always fails, but that’s to be expected. After running through it over and over again, I find the bugs and squash them. Sometimes it’s a really stupid human error on my part, sometimes it’s something that a sensor or part can’t do and you have to find a different way. In the end, it gets the job done, sometimes in a completely different way then when I started.

This is the way I personally programmed this year. You can do it mostly any way you want, as long as it works for you and your team.

Simply put, there is no ‘right way’. It depends on your style, the other developers that you work with, your team, and the features that you want to implement. Generaly, do a lot of testing. It’ll pay off at the competition.

I agree with those above.

Some things that many professional programmers do, can make programming easier. Right or wrong isn’t the issue - easier work is.

  1. Comment your code as you write it. For very obvious things, only a little commenting is OK, but for stuff that’s complex, explain what you’re doing. A year from now, it’ll help you figure out what you were thinking.

  2. Try little snippets of code to see if they work. Like building a robot, try each little piece to verify it works, then drop it into the ‘big’ program.

  3. Don’t be afraid to put in diagnostic code - things that will help you see what the program is doing every step of the way, so when something works unexpectedly, you can figure out why. (Comment this out for better performance later - but leave it in case you need it?)

  4. Back things up constantly, a few times a day. (I make a backup every 10-15 minutes!). And make true backups - don’t overwrite old versions, keep them! Disk space is cheap, as are USB memory sticks and external hard drives.

My 2 cents’

@Don I was terrible at commenting/diagnostic other than using the probe in LV which only helped occaisionally. I was backing up a lot at first but the usb drive i stored the backups on got filled in a week >.<

Definately try commenting, it will help.

thanks everybody for your comments!! This will definetly help me out alot for next year and teaching any new progammers who come on the team.