style updated and header fixes to match

doc/style.md

@@ -12,7 +12,7 @@ This document outlines the style for any C code that is to be stored within this
 
 # Code Layout
 ## Indentation
-Use 4 spaces for indentation, the only exception to this rule is for multi line comments
+Use 4 spaces for indentation, the only exception to this rule is for doxygen multi line comments
 
 Closing braces over multiple lines should match up with the initial declaration like:
 ```c
@@ -49,7 +49,7 @@ As of now there is no maximum line length
 ## Blank Lines
 As of now there should never be more than two blank lines next to each other
 
-## Organizing lines
+## Organizing Lines
 This is up to the programmer to decide what is most readable. The suggestion is to group lines together that relate to each other. Example:
 ```c
 void DOC_Type_ExampleFunction(){
@@ -63,7 +63,7 @@ void DOC_Type_ExampleFunction(){
 }
 ```
 
-## Inline functions
+## Inline Functions
 Do not use inline functions, always indent functions even if they are short. Example:
 ```c
 //do not do this
@@ -121,6 +121,9 @@ uint32_t *a, b, c;
 The only time to pass a value as a pointer is if:
     - It cannot be copied
     - It is being modified
+    - It is to be stored in a void *
+    - It is being created or destroyed
+    - The type is not defined in a header
 
 # Header Layout
 ## Include Guards
@@ -162,7 +165,7 @@ Before getting into naming conventions it is important to note that this style u
 ```
 DOC_
 ARC_
-TBYTE_
+EXAMPLE_
 NAMESPACE_
 ```
 
@@ -178,7 +181,7 @@ Defines and constants should be in all caps with a namespace and as descriptive
 ```c
 #define DOC_MEMORY_BLOCK_SIZE 6
 
-const uint8_t DOC_LOBY_MAX_ENTITIES 12;
+const uint8_t DOC_LOBBY_MAX_ENTITIES 12;
 ```
 
 ## Functions
@@ -202,7 +205,7 @@ typedef DOC_Bool (* DOC_Type_PollDataFn)(void *userdata);
 ```
 
 ## Variables
-Variables are lower camel case and should be as self documenting as possible, do not use acronyms (type out the full thing). Also using one letter is usually not recommended (x, y, and in for loops i can sometimes be ok). Remember readability is crucial.
+Variables are lower camel case and should be as self documenting as possible. Do not use acronyms, and try to avoid shortening words as much as possible. Also using one letter is usually not recommended (x, y, and i in for loops are times using single letters can be ok). Remember readability is crucial.
 
 # Herb's Suggestions
 I'd suggest avoiding ternary operators, else, and else if statements as much as possible. Usually returning instead of else statements makes the code more readable in my opinion. Also ternary operators almost always can be made more readable if put into an if statement.

include/arc/std/array.h

@@ -19,4 +19,4 @@ typedef struct ARC_Array {
 }
 #endif
 
-#endif //ARC_STD_ARRAY_H_
+#endif // !ARC_STD_ARRAY_H_

include/arc/std/bool.h

@@ -20,4 +20,4 @@ extern "C" {
 }
 #endif
 
-#endif //ARC_STD_BOOL_H_
+#endif // !ARC_STD_BOOL_H_

include/arc/std/hashtable.h

@@ -125,4 +125,4 @@ void ARC_Hashtable_RunIteration(ARC_Hashtable *hashtable, ARC_Hashtable_Iterator
 }
 #endif
 
-#endif //ARC_STD_HASHTABLE_H_
+#endif // !ARC_STD_HASHTABLE_H_

include/arc/std/io.h

@@ -39,4 +39,4 @@ void ARC_IO_WriteStrToFile(ARC_String *path, ARC_String *data);
 }
 #endif
 
-#endif //ARC_STD_IO_H_
+#endif // !ARC_STD_IO_H_

include/arc/std/queue.h

@@ -54,4 +54,4 @@ uint32_t ARC_Queue_Size(ARC_Queue *queue);
 }
 #endif
 
-#endif //ARC_STD_QUEUE_H_
+#endif // !ARC_STD_QUEUE_H_

include/arc/std/stack.h

@@ -54,4 +54,4 @@ uint32_t ARC_Stack_Size(ARC_Stack *stack);
 }
 #endif
 
-#endif //ARC_STD_STACK_H_
+#endif // !ARC_STD_STACK_H_

include/arc/std/string.h

@@ -379,4 +379,4 @@ void ARC_String_ReplaceMatchingCStringWithStrlen(ARC_String **string, char *patt
 }
 #endif
 
-#endif //ARC_STD_STRING_H_
+#endif // !ARC_STD_STRING_H_