3DSoftwareRenderer-DFSPR/Doc/Generator/Input/StyleGuide.txt

<- Manual.html | Back to main page

Title: Code convention for David Forsgren Piuva's Software Renderer

To keep the style consistent, the style being used in the library is explained in this document.
---
1. Use common sense! If it looks wrong to human readers then it's wrong. Don't defeat the purpose of any rule by taking it too far.
---
2. Don't use iterators when there is any other way to accomplish the task. You can't write efficient algorithms without knowing the data structures.
---
3. Tabs for indentation then spaces for alignment. It's the best of both worlds by both having variable length tabs	and correct alignment that works between lines of the same indentation.
---
4. No dangling else, use explicit {} for safety. Otherwise someone might add an extra statement and get random crashes.
---
5. No hpp extensions, use h for all headers. Could be either way, but this library uses *.h for compact naming, so keep it consistent.
---
6. C-style casting for raw data manipulation and C++-style for high-level classes.
When using assembly intrinsics and raw pointer manipulation to alter the state of bits,
verbose high-level abstractions only make it harder to count CPU cycles in your head.
Always use the tool that makes sense for the problem you're trying to solve.
C++ style is for things that are abstracted on a higher level.
C style is for when a byte is just a byte and you just want to manipulate it in a specific way.
---
7. Don't call member methods with "this" set to nullptr.
This would be undefined behavior and may randomly crash.
Use global functions instead. They allow checking pointers for null
because they are explicit arguments declared by the programmer.
---
8. Avoid using STD/STL directly in SDK examples.
Exposing types from the standard library should be done using an alias or wrapper in the dsr namespace.
This allow replacing the standard library without breaking backward compatibility.
The C++ standard libraries have broken backward compatibility before and it can happen again.
---
9. Don't abuse the auto keyword everywhere just to make it look more "modern".
Explicit type safety is what makes compiled languages safer than scripting.
---
10. No new line for opening brackets.
Makes the code more compact and decreases the risk of copy-paste errors.
---
11. Don't fix the style of someone else's code if you can easily read it.
Especially if there's no style rule explicitly supporting the change.
Otherwise style changes will defeat the purpose by introducing more version conflicts.
---
12. Don't change things that you don't know how to test.
---