Compare commits
2 commits
7677dddd6b
...
c8c82d0000
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c8c82d0000 | ||
|
|
9ad7b07bc6 |
2 changed files with 55 additions and 16 deletions
47
STYLEGUIDE
47
STYLEGUIDE
|
|
@ -2,10 +2,7 @@
|
||||||
Style Guide
|
Style Guide
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This document serves as a loose style guide for the repo.
|
This document outlines repo conventions and code style.
|
||||||
Generally, you should write code that follows the local
|
|
||||||
style of the file you're in, however, there are a few
|
|
||||||
conventions to keep in mind.
|
|
||||||
|
|
||||||
|
|
||||||
Getting Paid
|
Getting Paid
|
||||||
|
|
@ -40,6 +37,31 @@ message should only say 'finish [id]'.
|
||||||
finish 034
|
finish 034
|
||||||
|
|
||||||
|
|
||||||
|
Code Style
|
||||||
|
----------
|
||||||
|
|
||||||
|
Generally, I don't care what style of code is used. It's
|
||||||
|
more important that you stay in line with the local style
|
||||||
|
of the file you're in.
|
||||||
|
|
||||||
|
Things I actually care about:
|
||||||
|
|
||||||
|
- Don't be clever. Write code that does the job;
|
||||||
|
nothing more, nothing less.
|
||||||
|
|
||||||
|
- Comment your code. I very much disagree with the
|
||||||
|
premise that code is self-documenting. Take a step
|
||||||
|
back and write a comment (with your name) that
|
||||||
|
explains *why* you're doing *what* you're doing.
|
||||||
|
Please try to stick to this format:
|
||||||
|
@note, @todo, @temp, @allocates, @leak
|
||||||
|
|
||||||
|
- Descriptive names. In general, it's fine to use short
|
||||||
|
names for local variables. However, you should
|
||||||
|
almost always opt for longer, more descriptive names
|
||||||
|
in every other context.
|
||||||
|
|
||||||
|
|
||||||
Imports
|
Imports
|
||||||
-------
|
-------
|
||||||
|
|
||||||
|
|
@ -81,6 +103,23 @@ When authoring a new module, use this as a base plate:
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Bindings
|
||||||
|
--------
|
||||||
|
|
||||||
|
Binding modules should default to static linking and take
|
||||||
|
an optional '#module_parameter' to link dynamically.
|
||||||
|
Libraries should be pinned to a specific version, and all
|
||||||
|
binaries (.dll, .dylib, etc.) *must* be checked into
|
||||||
|
source control. If possible, use the release build of the
|
||||||
|
library that includes debug information.
|
||||||
|
|
||||||
|
Bindings should stay as close as possible to the original
|
||||||
|
library. To jai-ify the bindings, create a submodule
|
||||||
|
called 'wrapper' that import and wraps the api.
|
||||||
|
|
||||||
|
See: 'thirdparty/raylib' for example bindings.
|
||||||
|
|
||||||
|
|
||||||
OS-Specific Code
|
OS-Specific Code
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
|
|
|
||||||
2
thirdparty/raylib/module.jai
vendored
2
thirdparty/raylib/module.jai
vendored
|
|
@ -1,4 +1,4 @@
|
||||||
#module_parameters(STATIC := false);
|
#module_parameters(STATIC := true);
|
||||||
|
|
||||||
#scope_export
|
#scope_export
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue