Compare commits
No commits in common. "c8c82d0000e72ddc4b90b2285a871f503e81044e" and "7677dddd6b057eb34083eaba613bb3b3de7cebe0" have entirely different histories.
c8c82d0000
...
7677dddd6b
2 changed files with 16 additions and 55 deletions
69
STYLEGUIDE
69
STYLEGUIDE
|
|
@ -2,7 +2,10 @@
|
||||||
Style Guide
|
Style Guide
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This document outlines repo conventions and code style.
|
This document serves as a loose style guide for the repo.
|
||||||
|
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
|
||||||
|
|
@ -23,43 +26,18 @@ message should only say 'finish [id]'.
|
||||||
Author: Your Name <your@email>
|
Author: Your Name <your@email>
|
||||||
|
|
||||||
start 034
|
start 034
|
||||||
|
|
||||||
// Intermediate commits
|
// Intermediate commits
|
||||||
commit SOME HASH
|
commit SOME HASH
|
||||||
Author: Your Name <your@email>
|
Author: Your Name <your@email>
|
||||||
|
|
||||||
Blah blah blah
|
Blah blah blah
|
||||||
|
|
||||||
// Final commit
|
// Final commit
|
||||||
commit SOME HASH
|
commit SOME HASH
|
||||||
Author: Your Name <your@email>
|
Author: Your Name <your@email>
|
||||||
|
|
||||||
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
|
||||||
|
|
@ -71,16 +49,16 @@ standalone library that doesn't rely on compiler-shipped
|
||||||
modules (unless absolutely required).
|
modules (unless absolutely required).
|
||||||
|
|
||||||
basic :: #import "Basic";
|
basic :: #import "Basic";
|
||||||
|
|
||||||
When importing 'jc' modules, ALWAYS namespace them and use
|
When importing 'jc' modules, ALWAYS namespace them and use
|
||||||
absolute import paths. '#import,file' does not function
|
absolute import paths. '#import,file' does not function
|
||||||
the same as '#import' and causes issues when mixed
|
the same as '#import' and causes issues when mixed
|
||||||
with '#load'. '_run_all_tests.jai' is an exception to
|
with '#load'. '_run_all_tests.jai' is an exception to
|
||||||
this rule.
|
this rule.
|
||||||
|
|
||||||
math :: #import "jc/math";
|
math :: #import "jc/math";
|
||||||
|
|
||||||
|
|
||||||
Modules
|
Modules
|
||||||
-------
|
-------
|
||||||
|
|
||||||
|
|
@ -94,31 +72,14 @@ When authoring a new module, use this as a base plate:
|
||||||
|
|
||||||
// Within module_name/module.jai
|
// Within module_name/module.jai
|
||||||
#module_parameters(RUN_TESTS := false); // Should be the last parameter if others are required
|
#module_parameters(RUN_TESTS := false); // Should be the last parameter if others are required
|
||||||
|
|
||||||
#load "file_a.jai";
|
#load "file_a.jai";
|
||||||
#load "file_b.jai";
|
#load "file_b.jai";
|
||||||
|
|
||||||
#if RUN_TESTS {
|
#if RUN_TESTS {
|
||||||
test :: #import "jc/test";
|
test :: #import "jc/test";
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
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
|
||||||
----------------
|
----------------
|
||||||
|
|
@ -133,7 +94,7 @@ switch statement over multiple files.
|
||||||
case .LINUX;
|
case .LINUX;
|
||||||
case; #assert false, "unimplemented platform";
|
case; #assert false, "unimplemented platform";
|
||||||
}
|
}
|
||||||
|
|
||||||
If multiple files are required, use these file suffixes
|
If multiple files are required, use these file suffixes
|
||||||
and conditionally '#load' them based on 'OS'.
|
and conditionally '#load' them based on 'OS'.
|
||||||
|
|
||||||
|
|
|
||||||
2
thirdparty/raylib/module.jai
vendored
2
thirdparty/raylib/module.jai
vendored
|
|
@ -1,4 +1,4 @@
|
||||||
#module_parameters(STATIC := true);
|
#module_parameters(STATIC := false);
|
||||||
|
|
||||||
#scope_export
|
#scope_export
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue