Update 'Style Guide'

Style-Guide.md

@@ -46,16 +46,21 @@ err = parser.nextToken()
 if err != nil { return }
 ```
 
-# Pass By Value, Not by Reference
+# Arguments and Returns
+
+## Pass By Value, Not by Reference
 
 Always pass by value and return by value unless there is an explicit semantic reason not to do so, or the data you are passing is exceptionally large in size. Stack memory is more performant, and passing by reference can add complexity to your code (and increase the likliehood of annoying segfaults).
-# Returning Values
+
+## Returning Values
 
 Golang lets you return multiple values from functions, and it also allows you to give them names. When writing a function, you should name all return values, even if there is only one of them. Always return values by *setting* your returns and then using a naked return statement like this:
 
 ```
-func someFunction () (value int, err error) {
-	_, value, err = otherFunction(5)
+func someFunction () (someResult SomeResult, err error) {
+	someResult.x, err = someOtherFunction
+	if err != nil { return }
+	someResult.y = 6
 	return
 }
 ```
@@ -64,6 +69,38 @@ View the return statement like a `break` statement, but for functions.
 
 Some may claim that using naked returns like this is a bad idea, but it is incredibly useful when parsing/lexing things, as if you encounter an error you can return *what you have so far*. Thus, this is the dominant pattern in the ARF compiler.
 
-# Nesting
+# Nesting and Indentation
 
-If you're indenting more than 4 times you should look into breaking up your code into more functions/methods. The control flow of functions with that much nesting can be very difficult to analyze.
+If you're indenting more than 4 times you should look into breaking up your code into more functions/methods. The control flow of functions with that much nesting can be very difficult to analyze.
+
+Use an indentation size of 8 when working on the compiler. The code should not extend beyond the 80 column line. This rule can be broken if and only if doing otherwise would negatively affect the code's readability in a significant way.
+
+Some strategies for reducing horizontal sprawl if a line is getting too long:
+
+```
+someFunc(
+	relatedInput1, relatedInput2,
+	differentInput1, differentInput2)
+
+x :=
+	"some long string " +
+	"the other part of " +
+	"the long string."
+
+x := "some long string "
+x += "the other part of "
+x += "the long string."
+
+func someFunc(
+	input1 int, input2 int,
+) (
+	output1 int, output2 int,
+) {
+	// some code
+	return
+}
+```
+
+Obviously, these examples have been condensed way below 80 columns for dramatic effect, but you get the idea.
+
+Other stylistic choices don't matter as much, since all of the code will be gofmt'd at some point. It is, however, a good idea to adopt the gofmt style at least to some degree, so your code will look similar before and after.