Schik wrote:
I was wondering if somebody could give me a quick rundown on the coding standards used in DROD? The variable naming is a bit (read: a lot) different than what I\'m used to, though I\'ve seen similar to your style in books.
Yeah, this is the \"
hungarian notation\"
--a gift from Microsoft. Different programmers choose different prefixes to indicate the type of variable, but the ones I use (with some inconsistency) are:
w - unsigned short
n - signed short
dw - unsigned long
l - signed long
b - boolean
byt - byte
c - char
sz - null-terminated char array
wcz - null-terminated wide char array
str - STL string
wstr - STL wide char string
dbl - double
sgl - single
p - pointer to something. If it is one of the above types, I\'d probably combine the prefixes, i.e. pl.
h - handle to something.
arr - An array of something.
I tried to do mine similar to what I saw, but going back through it I see places where I use my own conventions. It would be easier for me to follow DROD conventions given a couple quick & easy rules.
I\'d feel bad about imposing rules on you. However, I understand that it is good to be consistent. I usually emulate the style and design of other code when I join a project and take some pride in staying flexible. In the DROD project, I\'ve let people code in whatever style suited them. When I added code to functions they authored, I even tried to write my code in their style for that one function. So most style things don\'t matter too much to me.
Mainly, I like to see comments that describe what functions and code inside them do.
It would be nice to follow the verb-noun naming convention for functions, and try to reuse existing verbs when appropriate. As much as possible, it should be clear what a function does by its name. I have made some spectacularly long function names to do this.
The only global variables we have (module-scope declarations with extern declarations in other modules) are singleton objects. Well, maybe there is an exception somewhere, but I don\'t like global variables. Generally, variable scopes should be made as small as possible, sacrificing convenience and performance at times to make safer and clearer code.
Feel free to load your code up with ASSERT macros to catch debug errors. Functions should generally not return for debug errors, however there are many times when I break this rule because I don\'t want to crash a released app. In other words, I concede at times that I might not catch a particularly important debug error before the release is made.
Exception-handling (try...catch) is not used.
Use one of the C++ cast operators for casting (static_cast, dynamic_cast, reinterpret_cast) instead of the C-style casting.
Multiple inheritance is done, but reluctantly. It\'s preferred to embed extra classes as members or revise the base classes to avoid multiple inheritance.
Ack. I don\'t want to go on and on. I think the project shouldn\'t contain much in the way of coding standards, but here I go spewing them out. Mainly, just remember to comment things, and I can catch most \"
offenses\"
on review and change code myself if it\'s important.
Thank you for asking (and I hope you don\'t regret it
). It is most conscientious of you!
-Erik
____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals |
twitch stream |
youtube archive (NSFW)