summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKrutonium <PFCKrutonium@gmail.com>2020-09-30 12:54:57 +0200
committerKrutonium <PFCKrutonium@gmail.com>2020-09-30 12:54:57 +0200
commit786ce15ab01a65436062bed8d6a7691b93972048 (patch)
tree2b7b12004c7e75cc70e18fee127fea5f0e81f9aa
parentFix more (diff)
downloadre3-786ce15ab01a65436062bed8d6a7691b93972048.tar
re3-786ce15ab01a65436062bed8d6a7691b93972048.tar.gz
re3-786ce15ab01a65436062bed8d6a7691b93972048.tar.bz2
re3-786ce15ab01a65436062bed8d6a7691b93972048.tar.lz
re3-786ce15ab01a65436062bed8d6a7691b93972048.tar.xz
re3-786ce15ab01a65436062bed8d6a7691b93972048.tar.zst
re3-786ce15ab01a65436062bed8d6a7691b93972048.zip
-rw-r--r--CODING_STYLE.md107
-rw-r--r--README.md111
2 files changed, 109 insertions, 109 deletions
diff --git a/CODING_STYLE.md b/CODING_STYLE.md
new file mode 100644
index 00000000..b8be02bc
--- /dev/null
+++ b/CODING_STYLE.md
@@ -0,0 +1,107 @@
+# Coding style
+
+I started writing in [Plan 9 style](http://man.cat-v.org/plan_9/6/style),
+but realize that this is not the most popular style, so I'm willing to compromise.
+Try not to deviate too much so the code will look similar across the whole project.
+
+To give examples, these two styles (or anything in between) are fine:
+
+```
+type
+functionname(args)
+{
+ if(a == b){
+ s1;
+ s2;
+ }else{
+ s3;
+ s4;
+ }
+ if(x != y)
+ s5;
+}
+
+type functionname(args)
+{
+ if (a == b) {
+ s1;
+ s2;
+ } else {
+ s3;
+ s4;
+ }
+ if (x != y)
+ s5;
+}
+```
+
+This one (or anything more extreme) is heavily discouraged:
+
+```
+type functionname ( args )
+{
+ if ( a == b )
+ {
+ s1;
+ s2;
+ }
+ else
+ {
+ s3;
+ s4;
+ }
+ if ( x != y )
+ {
+ s5;
+ }
+}
+```
+
+i.e.
+
+* Put the brace on the same line as control statements
+
+* Put the brace on the next line after function definitions and structs/classes
+
+* Put an `else` on the same line with the braces
+
+* Don't put braces around single statements
+
+* Put the function return type on a separate line
+
+* Indent with TABS
+
+As for the less cosmetic choices, here are some guidelines how the code should look:
+
+* Don't use magic numbers where the original source code would have had an enum or similar.
+Even if you don't know the exact meaning it's better to call something `FOOBAR_TYPE_4` than just `4`,
+since `4` will be used in other places and you can't easily see where else the enum value is used.
+
+* Don't just copy paste code from IDA, make it look nice
+
+* Use the right types. In particular:
+
+ * don't use types like `__int16`, we have `int16` for that
+
+ * don't use `unsigned`, we have typedefs for that
+
+ * don't use `char` for anything but actual characters, use `int8`, `uint8` or `bool`
+
+ * don't even think about using win32 types (`BYTE`, `WORD`, &c.) unless you're writing win32 specific code
+
+ * declare pointers like `int *ptr;`, not `int* ptr;`
+
+* As for variable names, the original gta source code was not written in a uniform style,
+but here are some observations:
+
+ * many variables employ a form of hungarian notation, i.e.:
+
+ * `m_` may be used for class member variables (mostly those that are considered private)
+
+ * `ms_` for (mostly private) static members
+
+ * `f` is a float, `i` or `n` is an integer, `b` is a boolean, `a` is an array
+
+ * do *not* use `dw` for `DWORD` or so, we're not programming win32
+
+* Generally, try to make the code look as if R* could have written it
diff --git a/README.md b/README.md
index 8d5b4c0c..41e5a094 100644
--- a/README.md
+++ b/README.md
@@ -21,8 +21,7 @@ such that we have a working game at all times.
## Preparing the environment for building
-- Clone the repo.
-- Run `git submodule init` and `git submodule update`.
+- Clone the repo using the argument `--recursive`.
- Point GTA_III_RE_DIR environment variable to GTA3 root folder.
- Run premake
- On Windows: one of the `premake-vsXXXX.cmd` variants on root folder
@@ -36,6 +35,7 @@ such that we have a working game at all times.
> :information_source: **Did you notice librw?** re3 uses completely homebrew RenderWare-replacement rendering engine; [librw](https://github.com/aap/librw/). librw comes as submodule of re3, but you also can use LIBRW enviorenment variable to specify path to your own librw.
## Contributing
+Please read the [Coding Style](https://github.com/GTAmodding/re3/blob/master/CODING_STYLE.md) Document
### Unreversed / incomplete classes (at least the ones we know)
The following classes have only unused or practically unused code left:
@@ -44,110 +44,3 @@ CCullZone - only mobile stuff
CCullZones - only mobile stuff
```
-### Coding style
-
-I started writing in [Plan 9 style](http://man.cat-v.org/plan_9/6/style),
-but realize that this is not the most popular style, so I'm willing to compromise.
-Try not to deviate too much so the code will look similar across the whole project.
-
-To give examples, these two styles (or anything in between) are fine:
-
-```
-type
-functionname(args)
-{
- if(a == b){
- s1;
- s2;
- }else{
- s3;
- s4;
- }
- if(x != y)
- s5;
-}
-
-type functionname(args)
-{
- if (a == b) {
- s1;
- s2;
- } else {
- s3;
- s4;
- }
- if (x != y)
- s5;
-}
-```
-
-This one (or anything more extreme) is heavily discouraged:
-
-```
-type functionname ( args )
-{
- if ( a == b )
- {
- s1;
- s2;
- }
- else
- {
- s3;
- s4;
- }
- if ( x != y )
- {
- s5;
- }
-}
-```
-
-i.e.
-
-* Put the brace on the same line as control statements
-
-* Put the brace on the next line after function definitions and structs/classes
-
-* Put an `else` on the same line with the braces
-
-* Don't put braces around single statements
-
-* Put the function return type on a separate line
-
-* Indent with TABS
-
-As for the less cosmetic choices, here are some guidelines how the code should look:
-
-* Don't use magic numbers where the original source code would have had an enum or similar.
-Even if you don't know the exact meaning it's better to call something `FOOBAR_TYPE_4` than just `4`,
-since `4` will be used in other places and you can't easily see where else the enum value is used.
-
-* Don't just copy paste code from IDA, make it look nice
-
-* Use the right types. In particular:
-
- * don't use types like `__int16`, we have `int16` for that
-
- * don't use `unsigned`, we have typedefs for that
-
- * don't use `char` for anything but actual characters, use `int8`, `uint8` or `bool`
-
- * don't even think about using win32 types (`BYTE`, `WORD`, &c.) unless you're writing win32 specific code
-
- * declare pointers like `int *ptr;`, not `int* ptr;`
-
-* As for variable names, the original gta source code was not written in a uniform style,
-but here are some observations:
-
- * many variables employ a form of hungarian notation, i.e.:
-
- * `m_` may be used for class member variables (mostly those that are considered private)
-
- * `ms_` for (mostly private) static members
-
- * `f` is a float, `i` or `n` is an integer, `b` is a boolean, `a` is an array
-
- * do *not* use `dw` for `DWORD` or so, we're not programming win32
-
-* Generally, try to make the code look as if R* could have written it