Robocode v2: Real Programmers Don't Comment!

We are once again back at our robocode basics, finishing up unfinished code and fine tuning it for review. Movement01 doesn't do anything, so what is there to fine tune?

The main task this week was to implement RoboCoding Standards into our code that conforms to the java standards set forth in our book, class, and RoboCode.

Click here to see my attempts at RoboCoding Standards.

Comments are easy right? We've been coding for years!

As we saw in class; everyone, even the most experienced java programmer, can admit to breaking one or two standards. Trying to stick to a hundred different rules for coding is like trying to write an essay in proper English. Everyone has a different style of coding, yet we want to have a unified style of explaining what we write.

Just going back and reviewing my code, I had found huge amounts of violations that I had always though was correct. I had come to the conclusion that I was either an idiot or that standards for commenting change over the years.

One of the big things I noticed was the enormous amounts of end line comments. It seems like such a rampant thing that I always see people do. Well code monkey see, code monkey do, and like everyone who's made the mistake, the fact that bad commenting habits spread is a very important reason that being careful to stick to a proper uniform style is useful.

Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.

An interesting quote I saw on a shirt the other day had me wondering why we comment our code. The main reason I give for having comments is to allow others who may look upon your code to be able to read and have a clear sense of what is going on. Not everyone is a genius and can speak code, and not everyone is a genius in that they can write a program from start to finish without needing someone to review it.

These standards are there to allow us to map out our thought process to other coders. This allows cooperation between two unlike minded people. If you can't understand where one person is coming from and trying to do then how can you ever possible understand how their code works. But if we can write it down in a way that you can ready, although you may not understand their code, you can see how they are trying ti approach a problem.

It is also helpful, I believe, to have a very consistent and uniform for style to coding that we can easily read through ourselves. By avoiding writing redundant comments, and avoiding using third person. It creates a better overall flow in the though process and understanding when you read your's or another's code.