Some ado for things to do

23 10 2010

In a complete change of pace from the last few posts I’d like to go back to some C++ mainly because, well, I missed writing C++ code. [I haven’t finished the RunningCore but I’ll post up the complete code later and I’m sure no one would mind].

I’ve recently had a couple of conversations with people who have just started programming and I’ve seen code posted by other people who are going through the process and all of it reminded me of my first forays into the C++ language and the way we were taught it at school. The following are just some things I picked up on the way, they are my opinion of course and anyone can and probably will disagree with some of them if not all of them. Please feel free to comment [editing this I just realized it’s a pun, you’ll understand later] since I’m always up to learning new things and/or unlearning bad habits which is usually alot harder. So, without further ado, let’s start.

using namespace std;

This line is present in almost every tutorial or book I’ve seen and used by every teacher I met, all for the sake of brevity of code. Well guess what, the scoping operator is in the language to be used. C++ supports namespaces for a reason and it’s best to get students used to the fact that code is separated logically into ‘spaces. Exposing everything in a namespace like that will trample on other people’s code and cause annoying name clashes. If a function has too many ‘::’ in it for your liking the better alternative is to use a using directive local to that function.

int main(int argc, char* argv[])
  using std::cout;
  using std::endl;

  cout<<"Hello World!"<<endl;

Keeping with the namespace theme, put your code [yes I’m talking to you!] in your own namespace. The global namespace is full of things as it is, don’t add more to the party. Be proud of your code, own it. The global namespace will thank you and so would anyone coming after you that uses your code but also wants to have another function called Create() which does something completely different.

And another thing, comments are NOT your friend!
No, seriously, if someone tells you to document everything with comments then shoot them. Documenting algorithms should be in the documentation not in between the code lines. Comments are not meant for documentation purposes. They are also not used for this purpose:

void function()
  int i=0;
  int a=12;
  //i-=a*2; <------ This is NOT a good practice

If you comment a line, delete it, otherwise it’s flotsam, rubbish in the code stream. If you want to branch out from a particular codebase or just revert to some old code then use your VCS [Version Control System]. What, you aren’t using one! Stop writing code, just stop and go get one. Doesn’t matter if it’s Git, Mercurial, SVN or whatever. Your code is too precious to be left hanging without a VCS. And no, for the love of the gods [you know, Zeus, or Odin, or who ever you happen to believe in] DropBox IS NOT A VCS. If you ask around the office what kind of VCS they’re using and they tell you DropBox, RUN!

Hm… Where was I?
Documents, yeah. Coding standards are good, they’re good to have around and they’re good to document. I submitted a 6 page review in college for the coding standards our team was suppose to follow. I got a really good mark for it. I should have failed. Coding standards are only good if people follow them and people will only follow them if they can
A. Read them in a glance and,
B. Actually retain the rules in their head.

6 pages of documentation just for that allows for neither. Having globalized standards is important to any project but if they sit on more than 1 A4 page of 1.5 line-space, 12pt Ariel font then it’s a waste of time. Think hard about what’s important to you; items like, perhaps, Directory structure, Tabs vs. Spaces and indentation rules. A character count for global/local/static variables is useless [I had it in my particular document example and I wish I didn’t].

And just a few more for the road before I leave.
Braces, unlike commets, are your friends. They love you and they love us. They show everyone where everything lives and which lines belong to which if.

if (condition) { doSoemthing(); }
if (anotherCondition)

switch (lastCondition)
  case 0: { doSomething(); break; }
  case 1: { doSomething2(); break; }
  case 2:
  deafult: { handleDefault(); }

Clean and clear code can save lives you know, mostly yours if the maintainer has access to your address.
Get into good coding practices from the start. Don’t be fooled by tutorials or teachers telling you that it doesn’t matter. It does. And it’ll make life easier in the long run [just not the short one].

And one last, tiny little thing. If you have to include windows.h do it in a .cpp file, in a different directory on some else’s computer through a DLL. Worst header ever written…

“I think I’m a banana tree, Oh dear, I’m going slightly mad”




2 responses

23 10 2010

A brilliant post and some very good points. Throwing everything from the std namespace can result in some very weird errors ( for example).
Also, braces are one of the most important things to put in a coding practices document. You NEVER want to mix bracing styles in any code.

23 10 2010

and by ‘throwing’ I mean using 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: