Anuken/Mindustry
1
0
Fork 0
mirror of https://github.com/Anuken/Mindustry.git synced 2024-09-20 21:08:42 +03:00
Code Issues Projects Releases Wiki Activity

Anuken/Mindustry-Suggestions/issues/653

Browse Source
This commit is contained in:
Anuken 2020-09-30 15:12:38 -04:00 committed by GitHub
parent 27089f1057
commit 0b2c2c49b0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
CONTRIBUTING.md
View File

@ -4,22 +4,24 @@ This is for code contributions. For translations, see [TRANSLATING](TRANSLATING.
## Basic Guidelines ## Basic Guidelines
#### Use an IDE. ### Use an IDE.
Specifically, IntelliJ IDEA. Download the (free) Community Edition of it [here](https://www.jetbrains.com/idea/download/). Some people use other tools, like VS Code, but I would personally not recommend them for Java development. Specifically, IntelliJ IDEA. Download the (free) Community Edition of it [here](https://www.jetbrains.com/idea/download/). Some people use other tools, like VS Code, but I would personally not recommend them for Java development.
#### Always test your changes. ### Always test your changes.
Do not submit something without at least running the game to see if it compiles. Do not submit something without at least running the game to see if it compiles.
If you are submitting a new block, make sure it has a name and description, and that it works correctly in-game. If you are changing existing block mechanics, test them out first. If you are submitting a new block, make sure it has a name and description, and that it works correctly in-game. If you are changing existing block mechanics, test them out first.
### Do not make large changes before discussing them first.
#### Do not make large changes before discussing them first.
If you are interested in adding a large mechanic/feature or changing large amounts of code, first contact me (Anuken) via [Discord](https://discord.gg/mindustry) (preferred method) or via e-mail (*anukendev@gmail.com*). If you are interested in adding a large mechanic/feature or changing large amounts of code, first contact me (Anuken) via [Discord](https://discord.gg/mindustry) (preferred method) or via e-mail (*anukendev@gmail.com*).
For most changes, this should not be necessary. I just want to know if you're doing something big so I can offer advice and/or make sure you're not wasting your time on it. For most changes, this should not be necessary. I just want to know if you're doing something big so I can offer advice and/or make sure you're not wasting your time on it.
### Do not include packed sprites in your pull request.
When making a pull request that changes or adds new sprites, do not add the modified atlas & `spritesX.png` files to your final pull request. These are a frequent source of conflicts.
## Style Guidelines ## Style Guidelines
#### Follow the formatting guidelines. ### Follow the formatting guidelines.
This means: This means:
- No spaces around parentheses: `if(condition){`, `SomeType s = (SomeType)object` - No spaces around parentheses: `if(condition){`, `SomeType s = (SomeType)object`
- Same-line braces. - Same-line braces.
@ -29,10 +31,11 @@ This means:
- Do not use braceless `if/else` statements. `if(x) statement else statement2` should **never** be done. In very specific situations, having braceless if-statements on one line is allowed: `if(cond) return;` would be valid. - Do not use braceless `if/else` statements. `if(x) statement else statement2` should **never** be done. In very specific situations, having braceless if-statements on one line is allowed: `if(cond) return;` would be valid.
- Prefer single-line javadoc `/** @return for example */` instead of multiline javadoc whenver possible - Prefer single-line javadoc `/** @return for example */` instead of multiline javadoc whenver possible
- Short method/variable names (multipleLongWords should be avoided if it's possible to so reasonably, especially for variables) - Short method/variable names (multipleLongWords should be avoided if it's possible to so reasonably, especially for variables)
- Use wildcard imports - `import some.package.*` - for everything. This makes incorrect class usage more obvious (*e.g. arc.util.Timer vs java.util.Timer*) and leads to cleaner-looking code.
Import [this style file](.github/Mindustry-CodeStyle-IJ.xml) into IntelliJ to get correct formatting when developing Mindustry. Import [this style file](.github/Mindustry-CodeStyle-IJ.xml) into IntelliJ to get correct formatting when developing Mindustry.
#### Do not use incompatible Java features (java.util.function, java.awt). ### Do not use incompatible Java features (java.util.function, java.awt).
Android and RoboVM (iOS) do not support many of Java 8's features, such as the packages `java.util.function`, `java.util.stream` or `forEach` in collections. Do not use these in your code. Android and RoboVM (iOS) do not support many of Java 8's features, such as the packages `java.util.function`, `java.util.stream` or `forEach` in collections. Do not use these in your code.
If you need to use functional interfaces, use the ones in `arc.func`, which are more or less the same with different naming schemes. If you need to use functional interfaces, use the ones in `arc.func`, which are more or less the same with different naming schemes.
@ -41,7 +44,7 @@ The same applies to any class *outside* of the standard `java.[n]io` / `java.net
In general, if you are using IntelliJ, you should be warned about platform incompatiblities. In general, if you are using IntelliJ, you should be warned about platform incompatiblities.
#### Use `arc` collections and classes when possible. ### Use `arc` collections and classes when possible.
Instead of using `java.util.List`, `java.util.HashMap`, and other standard Java collections, use `Seq`, `ObjectMap` and other equivalents from `arc.struct`. Instead of using `java.util.List`, `java.util.HashMap`, and other standard Java collections, use `Seq`, `ObjectMap` and other equivalents from `arc.struct`.
Why? Because that's what the rest of the codebase uses, and the standard collections have a lot of cruft and usability issues associated with them. Why? Because that's what the rest of the codebase uses, and the standard collections have a lot of cruft and usability issues associated with them.
In the rare case that concurrency is required, you may use the standard Java classes for that purpose (e.g. `CopyOnWriteArrayList`). In the rare case that concurrency is required, you may use the standard Java classes for that purpose (e.g. `CopyOnWriteArrayList`).
@ -54,21 +57,21 @@ What you'll usually need to change:
- *Many others* - *Many others*
#### Avoid boxed types (Integer, Boolean) ### Avoid boxed types (Integer, Boolean)
Never create variables or collections with boxed types `Seq<Integer>` or `ObjectMap<Integer, ...>`. Use the collections specialized for this task, e.g. `IntSeq` and `IntMap`. Never create variables or collections with boxed types `Seq<Integer>` or `ObjectMap<Integer, ...>`. Use the collections specialized for this task, e.g. `IntSeq` and `IntMap`.
#### Do not allocate anything if possible. ### Do not allocate anything if possible.
Never allocate `new` objects in the main loop. If you absolutely require new objects, use `Pools` to obtain and free object instances. Never allocate `new` objects in the main loop. If you absolutely require new objects, use `Pools` to obtain and free object instances.
Otherwise, use the `Tmp` variables for things like vector/shape operations, or create `static` variables for re-use. Otherwise, use the `Tmp` variables for things like vector/shape operations, or create `static` variables for re-use.
If using a list, make it a static variable and clear it every time it is used. Re-use as much as possible. If using a list, make it a static variable and clear it every time it is used. Re-use as much as possible.
#### Avoid bloated code and unnecessary getters/setters. ### Avoid bloated code and unnecessary getters/setters.
This is situational, but in essence what it means is to avoid using any sort of getters and setters unless absolutely necessary. Public or protected fields should suffice for most things. This is situational, but in essence what it means is to avoid using any sort of getters and setters unless absolutely necessary. Public or protected fields should suffice for most things.
If something needs to be encapsulated in the future, IntelliJ can handle it with a few clicks. If something needs to be encapsulated in the future, IntelliJ can handle it with a few clicks.
#### Do not create methods unless necessary. ### Do not create methods unless necessary.
Unless a block of code is very large or used in more than 1-2 places, don't split it up into a separate method. Making unnecessary methods only creates confusion, and may slightly decrease performance. Unless a block of code is very large or used in more than 1-2 places, don't split it up into a separate method. Making unnecessary methods only creates confusion, and may slightly decrease performance.
## Other Notes ## Other Notes