10.18.2010

C++ coding conventions/standards

Since I want to use toolkit for assignments, too, I need to document and format it properly as well as giving it a consistent style, so it's easier for the controlling person to guess what's going on. Personally, I prefer using my own naming conventions and follow a distinct, always evolving programming guideline. As I noticed how outdated my toolkit was and how different it became after I decided to rethink everything, I though it couldn't harm to apply some typical coding conventions. One is, of course, naming. I do follow a specific guideline, but need to change if I want to get good marks. My personal conventions came from practice and the though to visually support my own code/work flow. For example, I always prefferred "rect.GetRect()" instead of "rect.getRect()", since the methods doesn't begin like a variable. I hate the other way, but I don't think I have a real chance to do it the other way. I mean this guy who will decide what mark I get works for IBM. He probably follows his company guidelines for coding style and doesn't only rate my program's function and class structure. Nope, I'll have to bite in the sour apple. Well, not bad at all. If there's a consistent and reasonable structure around, it shouldn't be too hard. Also, it improves readability for others who are also used to use such conventions. I always like to follow strict interface rules and try to review and change them regularly depending on new knowledge I archieved. Another good point is that if get used to naming conventions, I won't need to worry about it again. Coders are used to it, so it's getting easier for them to understand my code.

Most standards and guideline documents I found are from bigger companies like Google or even project-like organisations. Each guideline is specific and I couldn't find any appropriate match except for naming conventions or call-by-reference etc. I don't like how most of them handle their programmers. Nothing against their guidelines (although I doubt everything is a good choice), but today I heard horrible stories about software development market in general. Stuff like big companies firing entire dev teams just cause they noticed that the management did a shitty, but not the developers. I'm veeeeery suspicous of such big structures. You'll be just another factor, not a part in the puzzle. So a smaller dev team is much more acceptable for me, I think. I can't image working with so many people together. I'm kinda afraid of getting in an ugly meat machine.

However, I still think it's messy to start methods with a small letter. Why in hell did it come so far.

No comments: