[2024 dev2next] reading code

Speaker Marit van Dijk

For more see the table of contents


Notes

  • We spend more time reading code than writing code
  • Read code when adding features, fixing bugs, understand new codebase, when doing code review, when learning new technologies, etc
  • Up to 58% of time comprehending existing source code – Felienne Hermans, Programmer’s Brain
  • We spend time learning by writing code. We rarely deliberately practicing reading code
  • 1992 research – three groups. One learned by writing and reading code. One write and read but also explanations about code such as why made decisions. Last group only read code with those explanations. Second and third groups did better.

Code reading club

  • http://codereading.club
  • Marit participated in a monthly club – https://maritvandijk.com/code-reading-club/
  • Printed code sample that is 1-2 pages, structured exercises (ex: annotate code with markers)
  • Practice reading a variety of exercises
  • Focus on reading to understand rather than to judge

Example exercises

  • First glance – 1 minute.. Note the first and second thing that catches your eye. Think about why noticed first. Examples was in Groovy
  • Identify components and relationships – ex: methods
  • Identify the five most important lines. If don’t discuss up front what “most important” means, answers vary. The group then converged on what was most important
  • Identify concepts. Someone in the group is likely to know
  • Summarize what think code does

Lack of info

  • Could be short or long term, details, names, too many things
  • Chunking – 3-5 things

Lack of knowledge

  • language, constructs, business domain
  • Create a list of what don’t know, research and memorize if relevant

Lack of processing power

  • Too much to keep track of
  • Dependency graph – on paper, draw arrows to show where variable used
  • State table – keep track of variable values

Dimensions of code reading

  • Structure – we don’t read linearly. More experienced programmers scan code a lot before focusing on a piece
    • Domain – data
  • Concepts – programming and domain
  • Context – why app written, who uses it

Getting started

  • Checkout the code. Proves found project and have access
  • Look at package structure. How many? Names? If see name unfamiliar with, add to list so look up what means later
  • Build project to ensure can
  • Read readme.md. Tip: Check readme to ensure clear how to build and test application
  • See if can run locally and explore in UI if possible
  • Find starting point – main method, export
  • Docs 0 exL swagger

IntelliJ Features

  • AI assistant – Prompt to ask what’s wrong and how to fix
  • Generate diagram to show relationships between classes. Tip: draw own to focus on part interested in and remember it better
  • Generate matrix showing relationship between modules. SHows number of dependencies as well.
  • Can trace code outside in and see where leads
  • Endpoints view – to go a part of the code.
  • Be able to search/navigate without thinking

Outside IDE

  • Identify use case
  • Draw own diagrams

Understanding code

  • structured exercises can help
  • start with the thing you noticed in the 1 minute example to get past being stuck
  • IDE can help you
  • syntax highlighting
  • pull up documentation in pop up
  • pull up code in pop up
  • collapse sections of code
  • find references
  • view tests – hopefully their names express the indended behavior
  • debugger
  • AI assistant can give summary of a commit or set of commits

My take

The code was way too small on the 1 minute example. It was fine on everything else.. Marit invited us to move. Two people (I was one) sat on the floor in the font. I liked the demo. My brain was full before the session started though.

using switch expressions with sax

It’s been a lot of years since I used SAX so I wrote my handler method the way I remember it looking:

if (qualifiedName.equals("edition") || qualifiedName.equals("author")) {
   inTagWithText = true;
}
if (qualifiedName.equals("book")) {
   System.out.println(attributes.getValue("title"));
} else if (qualifiedName.equals("paperback")) {
   paperback = true;
} else if (qualifiedName.equals("authors")) {
   System.out.println("Paperback? " + paperback);
}

IntelliJ suggested that this would be better with a switch. It was right. The new code is:

switch (qualifiedName) {
   case "edition", "author" -> inTagWithText = true;
   case "paperback" -> paperback = true;
   case "authors" -> System.out.println("Paperback? " + paperback);
   case "book" -> System.out.println(attributes.getValue("title"));
   }
}

Thank you IntelliJ. That looks much better.

Surrounding with Double Quotes in IntelliJ

IntellIJ has a feature where you can surround a String with double quotes by simply pressing “. Here’s how:

  1. Select the text you want in quotes
  2. Press “

There’s a video showing the feature.

However, this may appear not to work on your machine. There are two possible causes

Cause #1: The feature is off

Go into your IDE settings and choose

  1. Editor
  2. General
  3. Smart Keys
  4. Check “Surround selection on typing quote or brace”

Cause #2: Keyboard mapping

I’m on a Mac and the feature worked for single quotes and not double quotes. How odd. It’s clearly not cause #1 since it works for single quotes.

I then tried on my laptop keyboard and it worked with double quotes. So clearly the problem was my keyboard! Somehow it was being treated as an international keyboard instead of US. I remapped by going to “Keyboard” on Mac system settings and choosing “setup keyboard.”

Once I did this, the feature worked consistently on both keyboards.

Makes me wonder how people with non-US keyboards are supposed to use the feature!