1
by thindil
initial import |
1 |
My style of function naming may seem a little bit odd (and, I would agree) but |
2 |
there is a method to the madness that I will try and explain here for you all: |
|
3 |
||
4 |
I'm making an attempt to modularize as many datastructures as I can, making it |
|
5 |
so people can only interact with them through the header files; I'm guessing it |
|
6 |
will cut down on bugs by forcing people to reuse already existing functions |
|
7 |
instead of writing their own, which are known to (hopefully) work correctly. |
|
8 |
I've tried to distinguish between functions designed to interact directly with |
|
9 |
datastructures (e.g. get and set methods) and those that actually have some |
|
10 |
functionality to them (e.g. sending messages to sockets, combat routines, etc) |
|
11 |
by using different casing. Functions that are deisgned to interact directly |
|
12 |
with a datastructure are in CamelCase and everything else is in snakey_case. |
|
13 |
||
14 |
For functions in CamelCase, functions should take a naming syntax like: |
|
15 |
[datatype][routine][target] (e.g. roomGetName, roomRead). The exception is |
|
16 |
for creating and deleting datastructures. For doing these things, it is always |
|
17 |
[new | delete][datatye] (e.g. newList, deleteChar). |
|
18 |
||
19 |
Hopefully this will explain the seemingly odd programming style you see in my |
|
20 |
code. Undoubtedly, this is a very bad convention to use (I would be better off |
|
21 |
using one type of casing or the other) but that's life, I guess. Perhaps in a |
|
22 |
later version, I will go through and redo the function naming conventions. |
|
23 |
||
24 |
Geoff Hollis |
|
25 |
hollisgf@email.uc.edu |
|
26 |
http://www.uc.edu/~hollisgf/ |