The document presents seven rules for improving code readability according to Per Lundholm, emphasizing that readability is crucial for maintaining and fixing code. The rules include rewriting code after initial writing, avoiding comments, using good naming conventions, extracting nested loops, limiting method lengths to a maximum of seven lines, adhering to consistent formatting, and rewriting unreadable code. These guidelines encourage developers to focus on creating code that is clear and easy to understand while also engaging in discussions about their own readability principles.

1. 7 rules on code readability
Per Lundholm
What I say

2. What makes good code?
Many things but whatever the qualities are,
readability is a cornerstone.
If you can’t read the code, you can’t fix it.

3. Per Lundholm
Rules list
1. Rewrite what you wrote
2. No comments
3. Good Names
4. Extract nested loops
5. Maximum 7 lines
6. Formatting
7. If you can’t read it, rewrite

4. Per Lundholm
1. Rewrite what you wrote
When you first solve a problem, you’re
focused on the problem solving. That
seldom results in readable code.
If you immediately rewrite, you still have a
deep understanding of the solution and are
thus in a optimal position to do it.

5. Per Lundholm
2. No comments
Avoid comments.
If you’re not allowed to use comments, you
force yourself to write readable code.
They have a tendency to rot. An outdated
comment is far worse than no comments at all,
since it will just confuse the reader.

6. Per Lundholm
2. No comments (2)
Interface documentation
APIs are a different thing though, as comments
are used to create documentation for readers
that do not necessarily have access to the
implementation. But that’s not comments, that’s
interface documentation.
Don’t use comments to make up for
unreadable code.

7. Per Lundholm
3. Good Names
Names should be short, to the point.
Cryptic abbreviations should be avoided,
unless well established like PDF.
If lines get too long due to long names,
readability drops. Too short names risk
getting cryptic.

8. Per Lundholm
Type inferred variable names
Only if they are the only one of that type in
the context

9. Per Lundholm
Test methods
I’ve given up on camel case and switched
to underscore instead.
Is not a name, it is a sentence.
// CamelCase
public void givenAPeerReviewTestWhenAtHandInPageThenHandInBlankButtonIsInvisible() {
}
// Underscore
public void given_a_peer_review_test_when_at_hand_in_page_then_hand_in_blank_button_is_invisible() {
}

10. Per Lundholm
4. Extract nested loops
Nested loops never reads well, avoid them.
Extract the inner loop into a new method.

11. Per Lundholm
5. Maximum 7 lines
Methods should be no longer than 7 lines
long, preferably even shorter.
If you break this rule, you present too many
details to the reader at once. Only count lines
that adds to the cognitive overhead, not empty
lines or lines with a single brace.

12. Per Lundholm
Extract chunks of code into new
methods
Extract chunks of code into new methods
and name them well.
Every method should have a single
responsibility so watch out for names with
“and” in them.

13. Per Lundholm
Tip: prepare for ‘extract method’
Prepare for ‘extract method’
by changing order of
statements
The first is in chunks of
methods, making it hard to
do the ‘extract method’
refactoring
Now you can extract a
method from the first two
lines and call it twice instead.

14. Per Lundholm
6. Formatting
No, you can’t have your own formatting
rules and I shouldn’t need to tell you why.
Just apply the agreed upon formatting as
often as possible.
And remove those empty lines you created
when trying to think. :)

15. Per Lundholm
7. If you can’t read it, rewrite
If you can’t read the code, it should be
rewritten.
Rewriting the code increases your
understanding.
Check-in the readability fix separately from
other changes.

16. Per Lundholm
Epilogue
These are just my thoughts, but it pays off
to consciously think about what you believe
makes code readable.
What are your rules? Write them down!
Show them to someone and discuss.