Update style guides around complexity (#213)

doc/java-style-guide.md

@@ -19,6 +19,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
   - [TODO Comments](#todo-comments)
   - [Other Comment Usage](#other-comment-usage)
 - [Program Design](#program-design)
+  - [Code Complexity](#code-complexity)
   - [Testing and Benchmarking](#testing-and-benchmarking)
   - [Warnings, and Lints](#warnings-and-lints)
 
@@ -292,6 +293,17 @@ There are, of course, a few other situations where commenting is very useful:
 Any good style guide goes beyond purely stylistic rules, and also talks about
 design styles to use in code.
 
+### Code Complexity
+While we often have to write complex functionality, we want to ensure that the
+code itself is kept as simple and easy to read as possible. To do this, please
+use the following rules:
+
+- Write single-line expressions wherever possible, rather than writing one
+  complex chunk of code.
+- Separate intermediate results out to their own variables with appropriate
+  names. Even if they are temporaries, giving them a name is a great aid to code
+  comprehension.
+
 ### Testing and Benchmarking
 New code should always be accompanied by tests. These can be unit, integration,
 or some combination of the two, and they should always aim to test the new code

doc/rust-style-guide.md

@@ -20,6 +20,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
   - [TODO Comments](#todo-comments)
   - [Other Comment Usage](#other-comment-usage)
 - [Program Design](#program-design)
+  - [Code Complexity](#code-complexity)
   - [Safety](#safety)
   - [Testing and Benchmarking](#testing-and-benchmarking)
   - [Warnings, and Lints](#warnings-and-lints)
@@ -264,6 +265,17 @@ There are, of course, a few other situations where commenting is very useful:
 Any good style guide goes beyond purely stylistic rules, and also talks about
 design styles to use in code.
 
+### Code Complexity
+While we often have to write complex functionality, we want to ensure that the
+code itself is kept as simple and easy to read as possible. To do this, please
+use the following rules:
+
+- Write single-line expressions wherever possible, rather than writing one
+  complex chunk of code.
+- Separate intermediate results out to their own variables with appropriate
+  names. Even if they are temporaries, giving them a name is a great aid to code
+  comprehension.
+
 ### Safety
 Whereas most languages don't have a concept of _safety_, rust comes with a built
 in notion of `unsafe`. When working with `unsafe` functions and code blocks, you

doc/scala-style-guide.md

@@ -20,6 +20,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
   - [TODO Comments](#todo-comments)
   - [Other Comment Usage](#other-comment-usage)
 - [Program Design](#program-design)
+  - [Code Complexity](#code-complexity)
   - [Safety](#safety)
   - [Testing and Benchmarking](#testing-and-benchmarking)
   - [Warnings, and Lints](#warnings-and-lints)
@@ -344,6 +345,17 @@ There are, of course, a few other situations where commenting is very useful:
 Any good style guide goes beyond purely stylistic rules, and also talks about
 design styles to use in code.
 
+### Code Complexity
+While we often have to write complex functionality, we want to ensure that the
+code itself is kept as simple and easy to read as possible. To do this, please
+use the following rules:
+
+- Write single-line expressions wherever possible, rather than writing one
+  complex chunk of code.
+- Separate intermediate results out to their own variables with appropriate
+  names. Even if they are temporaries, giving them a name is a great aid to code
+  comprehension.
+
 ### Safety
 It is incredibly important that we can trust the code that we use, and hence we
 tend to disallow the definition of unsafe functions in our public API. When