A game engine for top-down 2D RPG games.
emmeline.girlkisser.top
rpg
game-engine
raylib
c99
1
2Style Guidelines
3================
4
5As a preface: I break these guidelines occasionally. It is
6important to note that I often find myself up into the
7early morning hours (sometimes even as early as 03:00)
8developing Keraforge. Late-night coding sessions tend to
9lead to mistakes that I accidentally push to prod. Feel
10free to point these mistakes out to me!
11
12Zen
13---
14
151. Keep types simple.
16 - If your type is complex enough to be unreadable, maybe
17 you should change your type.
18 - Function pointers may be disgraceful to write, but if
19 you write your code in such a way that avoids writing
20 the type more than once then you'll be fine.
21 - See: `struct kf_actorregistry`. I use some quirky
22 types there, but nothing too unreadable. Notice how I
23 never rewrite those types again and notice that I am not
24 using a typedef either.
25 - Additionally, if the user is never going to use that
26 type then it almost definitely does not need to be
27 typedef'd.
282. Documentation is important.
29 - "Self-documenting code" is not sufficient. If the item
30 is public then it should have an explanation.
31 - The ONLY exceptions to this rule are blatantly obvious
32 struct fields, such as `position`, `velocity`, etc.
33 - A few lines of documentation will save you a massive
34 headache in the future.
353. Macro magic is garbage, but unmaintainable code is worse.
36 - Using macro magic sparingly can help prevent you from
37 being smitten by the DRY deities. Save yourself today!
38 - See: math.h, log.h, and bini.h for cases where macro
39 magic is acceptable.
404. Keep names terse but readable.
41 - I don't want to see stdlib-style function names, but I
42 would much rather that over a name ripped from an
43 object-oriented C.
44 - If you must use a stdlib-style function name to remain
45 terse, then please provide a sentence in its docs to
46 explain the name.
475. Most importantly: Be simple.
48 - This often means sitting at your screen pondering the
49 best implementation for something rather than simply
50 using the first one that comes to mind.
51 - It's okay to sacrifice a bit of performance for more
52 maintainable code.
53 - If you must write complex code, please explain why via
54 a brief comment.
55
56Basics
57------
58
59See <etc/style.c> for a sample of the style with comments
60explaining each main point.
61
62For more specifics, please give a skim throughout the
63codebase itself.
64
65- Prefer [iuf](8|16|32|64) over (float|double|(u?int(8|16|32|64)_t)).
66- Do not typedef function pointers (see Zen #1), structs, enums, or unions.
67- Use global variables instead of requiring the user to maintain state.
68 See: kf_uiconfig, kf_actors, kf_actorregistry, kf_state, etc.
69- Use `struct kf_vec2(type)` instead of `struct kf_vec2f32`.
70- Do not modify libraries included in the source.
71 Those are: bini.h.
72- I'm not afraid to postfix _t to typedef'd types. The standard is useless here since we prefix kf_ anyway.
73 (I think this standard is useless *to begin with*, but I digress)