I worked on robots and automated tools….It seem to me that people/programmers who are new to programming in this style makes the mistakes. Although I am no expert, I do have a principle/rule I follow that help me develop my code better and the end results better. This is going to be a technical post specifically directed at programmers who are working on automated and/or autonomous programs or anyone who are working in the field
1) STOP USING WAIT FUNCTIONS
This is a big one especially in the robotics area. Normally we time ourselves in doing a task, so let’s say we’re driving a car and we need to turn. We visually see how close we are close to the curb before we turn, but for some reason when we’re tasked to make a robot to do this I bet you 9/10 programmers (esp. they’re beginner) is “We’ll make the robot drive to this distance, so that’s would be motors 100% for 5 second. Then turn for 3 second, then forward 10 second”
There are several flaws with that:
a) People don’t drive like that
b) If your batteries are low, then your distance will vary
c) That’s requires more trial and error
e) Wait functions usually “freeze up” the code until completion
Computers are fast, therefore you need to think in terms of “cycles”. A better way to approach this problem of just turning is use encoders.
Encoders are devices (I believe they comes in digital and analog) that report the revolution of the wheel, so one wheel revolution will be a value. Basically, “hey I just completed a turn.” Now with this value you know that you’re guaranteed that the wheel has travel the distance equal to its circumference (unless my physics is off) which means if you program the robot/software to keep moving the wheel until you get a value of x back from the encoder, you are guaranteed that it travels that distance and battery doesn’t not affect the encoder’s value unless the battery is dead, then there’s no value…(get the joke?)
Now another cool thing about working with encoders is that since you can basically say “while(encoderCycle != 25) do farts”, you can add some if statement and other stuff inside that loop to do other stuff in case you want to feed information or want the robot to react to something during the process of its driving… wait methods don’t do that…if you say drive for 5 second…it will drive for 5 second even if it is stuck against a wall
2) KEEP MAJOR FUNCTIONS IN ONE PLACE
Now some of you might disagree with me on this. When you’re writing a program that handles multiple functions such as organizing files, then uploading them, and etc, you should never have a function that calls another function that prints something pretty then calls another function that has the gritty stuff then calls another function that handles an error.
Now that sentence is just terrible and you’re already 3 level deep of the main function but then you have branches so now you’re 3 level deeps and have to deal with a, b, and c. This is spaghetti and I thank my old CS teacher who helped me get over my spaghetti code.
Keep the things you are doing and how you’re handling error and etc in one method. Split them when they’re not related, but do not split them too much. If I have a program that writes a file, I need to check if the file exist or if I have permission. That method/function should look like this
public void writeFile(string fileName){
try{
if(fileExit)
Console.write(“File Exist”);
else
File.write(fileName)
}catch(Exception ex){
Console.write(ex.toString());
}
}
Or something simple like that… and I apologize for the formatting (Tumblr is not cooperating)… See now that’s simple…it shouldn’t be like this
public void writeFile(string fileName){
try{
if(fileExit())
Console.write(“File Exist”);
else
Console.write(“wrote file”)
}catch(Exception ex){
Console.write(ex.toString());
}
}
public bool fileExist(){
bool file;
if(fileExit)
file = true;
else
file = false;
if (file)
File.write();
else
//you get the point
}
You get the point…what was the point of all that code? That’s what I been debugging and stuff…and just be glad that my variable name are understandable…which brings a good point
3) GOOD DESCRIPTIVE VARIABLE NAMES
As long as you’re not naming a varibale like “variableThatChecksForFile” or like “fkd” or even “word” (this was an actually variable name that I saw inside of a company code), you variable name should be self explanatory such as “hostName” or “hostStatus”…something when you first look at and you go “Ah, so this where it stores boops”….easy…
4) NEVER TOO MUCH DEBUG MESSAGES
Unless you’re spamming the console with “NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN NYAN” then there’s no such thing as too much debugging messages. By that I mean if you’re debugging a problem and you can’t step throw the code (step as in step in or step over) then add messages as markers to see what it’s doing, you can add breakpoints as well, but depending on what you’re testing you can’t always run it there and now…..
Make sure you’re debugging messages make sense for not only for yourself but for other employees/other programmers, because someone someday have to look at your code and if you put in “Error 69” and there’s no catalog or meaning behind this error, then you’re stuck. Don’t be misleading, I dealt with a message that an old code had and I thought it was a error but really it was misleading. “Error 69” which really meant “I don’t have an files”…Errors to me are actually like “This isn’t suppose to happen”…in my case that was suppose to happen!
I have a lot more tips/rants about programming, but tumblr is giving me problem blogging, so see you guys next time
