Formatted PATCHES.md

PATCHES.md

@@ -1,7 +1,7 @@
-Contributing to Akarin
-==========================
+# Contributing to Akarin
 
 ## Understanding Patches
+
 Patches to Akarin are very simple, but center around the directories 'Akarin-API' and 'Akarin-Server'
 
 Assuming you already have forked the repository:
@@ -18,6 +18,7 @@ These directories aren't git repositories in the traditional sense:
   - If it says something like `212 commits ahead, 207 commits behind`, then type `git fetch` to update spigot/paper
 
 ## Adding Patches
+
 Adding patches to Paper is very simple:
 
 1. Modify `Akarin-Server` and/or `Akarin-API` with the appropriate changes
@@ -28,7 +29,8 @@ Adding patches to Paper is very simple:
 
 Your commit will be converted into a patch that you can then PR into Paper
 
-## Help! I can't find the file I'm looking for!
+## Help! I can't find the file I'm looking for
+
 By default, Paper (and upstream) only import files that we make changes to.
 If you would like to make changes to a file that isn't present in Paper-Server's source directory, you
 just need to add it to our import script to be ran during the patch process.
@@ -48,11 +50,12 @@ to import it to create the first patch.
 
 To undo your changes to the file, type `git checkout scripts/importmcdev.sh`
 
-
 ## Modifying Patches
+
 Modifying previous patches is a bit more complex:
 
 #### Manual method
+
 In case you need something more complex or want more control, this step-by-step instruction does
 exactly what the above slightly automated system does.
 
@@ -73,6 +76,7 @@ exactly what the above slightly automated system does.
 9. PR your modifications back to this project.
 
 ### Method 2 (sometimes easier)
+
 If you are simply editing a more recent commit or your change is small, simply making the change at HEAD and then moving the commit after you have tested it may be easier.
 
 This method has the benefit of being able to compile to test your change without messing with your API HEAD.
@@ -86,13 +90,16 @@ This method has the benefit of being able to compile to test your change without
 6. PR your modifications to github
 
 ## Formatting
+
 All modifications to non-Paper files should be marked
+
 - Multi line changes start with `// Akarin start` and end with `// Akarin end`
 - You can put a messages with a change if it isn't obvious, like this: `// Akarin start - reason`
   - Should generally be about the reason the change was made, what it was before, or what the change is
   - Multi-line messages should start with `// Akarin start` and use `/* Multi line message here */` for the message itself
 - Single line changes should have `// Akarin` or `// Akarin - reason`
 - For example:
+
 ````java
 entity.getWorld().dontbeStupid(); // Akarin - was beStupid() which is bad
 entity.getFriends().forEach(Entity::explode());
@@ -104,6 +111,7 @@ Location spawnLocation = ((CraftWorld)entity.getWorld()).getSpawnLocation();
 entity.getWorld().explode(new BlockPosition(spawnLocation.getX(), spawnLocation.getY(), spawnLocation.getZ()));
 // Akarin end
 ````
+
 - We generally follow usual java style, or what is programmed into most IDEs and formatters by default
   - This is also known as oracle style
   - It is fine to go over 80 lines as long as it doesn't hurt readability
@@ -111,6 +119,7 @@ entity.getWorld().explode(new BlockPosition(spawnLocation.getX(), spawnLocation.
   - When in doubt, use the same style as the surrounding code
   
 ## Patch Notes
+
 When submitting patches to Akarin, we may ask you to add notes to the patch header.
 While we do not require it for all changes, you should add patch notes when the changes you're making are technical or complex.
 It is very likely that your patch will remain long after we've all forgotten about the details of your PR, patch notes will help
@@ -148,13 +157,17 @@ index a92bf8967..d0ab87d0f 100644
 ```
 
 ## Obfuscation Helpers
+
 In an effort to make future updates easier on ourselves, Akarin tries to use obfuscation helpers whenever possible. The purpose of these helpers is to make the code more readable. These helpers should be be made as easy to inline as possible by the JVM whenever possible.
 
 An obfuscation helper to get an obfuscated field may be as simple as something like this:
+
 ```java
 public final int getStuckArrows() { return this.bY(); } // Akarin - OBFHELPER
 ```
+
 Or it may be as complex as forwarding an entire method so that it can be overriden later:
+
 ```java
 public boolean be() {
     // Akarin start - OBFHELPER
@@ -166,5 +179,5 @@ public boolean pushedByWater() {
     return true;
 }
 ```
-While they may not always be done in exactly the same way each time, the general goal is always to improve readability and maintainability, so use your best judgement.
 
+While they may not always be done in exactly the same way each time, the general goal is always to improve readability and maintainability, so use your best judgement.