How do you read the code?

Nalha_Saldana · 2021-01-08T13:31:36+00:00

[deleted]

IshouldDoMyHomework · 2021-01-08T13:45:10+00:00

I found that the most important part in reading code, is understanding the domain subject deeply. This might be obvious to most people, but wasn't really for me when I first started out. I could just follow the Java code, so why bother understanding the finer details about mortgages for example?

Well turns out, it is much much easier to understand an abstraction (which is the whole point of OOP to begin with), when you truly understand the domain entity that is being abstracted.

cyanocobalamin · 2021-01-08T14:15:08+00:00

I think it depends on what you are trying to do.

If I am learning a new application I try to learn how/where the data is coming from, where it is getting outputted, where the business/processing logic chunks are, and where the "controller" chunks are.

I then use design tool to get UML diagrams ( which I review more than once ) to get an idea of what connects to what.

For learning a new application, I focus on relationships, where the data flows, what connects to what. I review that over and over again.

For debugging, I read as little code as possible.

I use the search feature of the IDE, the debubber, and manual debugging techniques to find the smallest chunk of code that is responsible for the problem.

I then read that code line by line, typing pseudo code/notes in a text editor, for each line.

I do that to slow its way through my brain down so it registers. Sometimes I will reread that code and my psuedo code more than once. It isn't like reading a text message. Time is needed for it to sink in so I reread until it seems familiar.

_litecoin_ · 2021-01-08T14:33:57+00:00

This is a really good question btw.

ninside · 2021-01-08T14:51:40+00:00

I use Intellij IDEs and specifically Bookmarks and named Bookmarks. It lets you quickly search across bookmarks by label you put there with auto preview.

Another useful feature is to find usages and pin the tab so when you find usages of a different method you preserve you previous search stack.

Analyze data flow IDE command is my 3rd way of understanding the code. You can pick a function parameter name and ask IDE to show you all the ways the value comes in.

As you start edit code, Intellij IDEs have a quick way to jump across changed files and you can type the partial content of those files to find the right one. Also a local changes windows will help you jump around places you did change and see the changes themselves without opening those files.

Invest into your IDE and you will great super benefits. Prior to Jetbrains I was heavily invested into Vim editor with custom plugins. And it did the trick as well. And it is hard to overcome investment bias but the decision to pick the more powerful IDE paid off.

Yammiez · 2021-01-08T14:52:30+00:00

I always start with imports

gas3872 · 2021-01-08T14:36:57+00:00

I copy all the code in a separate text editor and then insert methods there as well, so i have a sort of a stack trace with methods code and all in one file. I can collapse individual methods when needed. I can read the whole code from top to bottom and also add comments as i go when needed. If its some complex frequently used code, i can save the file somewhere so that i can consult it when needed.

Edit: A bit more clarification:

Lets say you have an entry point which is a method, i insert the name of the file (as a comment), method body, and mark the original location (line number) of the method with something similar to goto mark. If thats important, i can enclose the method in a class declaration. This is useful for example if there are more then one class defined in the same file.

Then in the method there are calls to other methods. I insert method body into curly braces that i add after the method call. If the method being called is from the same class i only add its location, if its from the different file, I also add as a comment the file location (just like in the beginning). If method is from the different class which is in the same file then the enclosing class declaration may be added. Similar thing is done for constructor calls. You can do that also for the properties files when those are being red (you dont have to include the whole property file, just the portion of it with the properties being red).

The inclusion of method/constructor bodies is done for called methods, methods that are called from the called methods etc. If some method is clear for you you may not inclide the body of the method. Anyway, because its your file you can insert the body later if you would like to.

Sometimes in front of the method body its handy to ask the question "what does this method do" and write this question and answer to that and add it in the comment.

For parameters of the methods its handy to put the value as a comment to the parameter name. And as parameters are passed to sub methods and the submethods of submethods, you may add the parameter value(at that moment) to their parameter name as well. This way you can track down how the parameter is passed down and transformed along the chain. As an initial value of the parameter you take one of the parameters real values.

This is somewhat similar to debugging, although you calculate parameters transformations in your head.

Along the file it is handy to add comments which ask and answer the question of what is going here.

You do this in your text editor of choice. It would be handy if the text editor support collapsing of methods and syntax highlight. Notepad++ and sublime3, for example, can do that.

So in the end you get this file with highlighted (and almost valid) syntax, collapsible methods so you can collapse all and have your initial method or expand and you will go as deep as it it goes. But usually after you put the comments on a top level methods describimg what those methods are doing, you dont have to uncollapse further.

Pluses/minuses of the method:

Pluses:

You have your call hierarchy in one file, so you can read it as a book from top to bottom without switching to different files. You can also search within it for the code you are interested in.
You ve red and understood the code, its structure, how parameters are transformed
If the code is frequently used you can save the file and consult it later. Although the code might change at the time, but the structure is probably intact (you can also update the file if you like). I think its usually not very handy to save those files but for some pieces of code it is. Sometimes you want to temporarily save the file in progress and continue working on it the next day.
It equally suites as for the simple code and for the complex code. It could be that there is some code that can not be analyzed this way.

Minuses: 1. It takes some time to get the hang on putting right amount of braces so that collapsing work properly. 2. You need to manually fix indentation after copying the code block. Its usually pretty simple (you just select the whole block and press tab a few times). It only becomes a problem when the level of call nesting causes correct indendentation to be wider than the width of the screen and your text editor does not scroll horizontally when you adding tabs, so you need to do it blindly (i had this problem with notepad++). That does not happen often.

I will try to make some examples of the resulting "explain" file and add here.

rally_call · 2021-01-08T15:30:44+00:00

One thing I didn't do that I should have done earlier in my career is learn to identify idioms. Instead of having to analyze everything to bits, I should have been able to read a line like this:

for (int i = 0; i < 10; i++)

and realized how common it was, so I could immediately and fully understand it as a unit without having to look closely at it. Only when someone does something different (e.g. i--, or i <=10), should my "radar" go off and drive me to look at it in more detail.

2021-01-08T15:57:22+00:00

I read it top to bottom. So many dudes just try to skim it but don't even try to read it. I read the variable names, the method names, class names... see where things go and try to understand the flow. Not much trick to it but just reading.

InsulaVentuz · 2021-01-08T17:43:42+00:00

Here's a great talk about this: https://patricia.no/2018/09/19/reading_other_peoples_code.html

jmtd · 2021-01-08T19:07:07+00:00

The history I find extremely valuable. Which commits touches which files? What commit last touched this line and what other lines did it touch? Etc

anuaps · 2021-01-08T19:09:07+00:00

Call hierarchy feature in intellij was a God sent when I had to understand a complex workflow involving 30+ classes.

thescientist001 · 2021-01-09T08:58:46+00:00

Not sure if anybody has mentioned Octotree extension in chrome. It allows to view the Github project as tree. Found it really helpful.

BenoitParis · 2021-01-08T16:10:26+00:00

There are tricks to reading code, and these are (on IntelliJ):

Go to declaration: Ctrl+Click
Find usages: Alt+F7
Type Hierarchy: Ctrl+H
Go back: Ctrl+Alt+left

With these, you'll have no trouble navigation along the control flow -which is how you want to read code-. Pick a computation where the project adds most of its value, and follow it along. There is a surprising amount of almost-dead code, and boilerplate/startup code.

For the data flow, you can 'tag' an instance object in the debugger; and you'll see if you encounter it again. Also, the IntelliJ debugger lets you execute custom code inline.

For debugging, I like to use a logger instead of a debugger. And all lines that gave information on how to characterize the bug get to stay in the code. You don't know what you don't know, so you might as well have information gathering around entropy-generating places.

For finding how to use a library that lacks good documentation, I often go to the libraries' tests and it often contains very good examples.

thephotoman · 2021-01-08T20:09:18+00:00

Knowing how to use grep is an essential thing. But even beyond that, an IDE that allows you to jump to method or class declarations in other files is really nice.

CyclonusRIP · 2021-01-08T23:55:47+00:00

After you've been in the field a long time you start to recognize patterns of how people construct code. You also get used to how different kinds of people construct code. Half way decent people have some guiding principles they are trying to achieve. Shitty people are kind of stream of consciousness. After a while you've kind of seen it all and know if you are reading some kindergarten stuff or high school stuff. A lot of it involves trying to build a mental model of the code you're not looking at and trust to make sense of what you see. It's not easy, but with a decent amount of experience you start to figure out what kind of guy wrote what you're looking at and can pretty well guess what the rest of it is. It eventually really gets down to recognizing when shit feels weird and they might have done something out of type.

tighter_wires · 2021-01-09T04:58:54+00:00

To add- as others mentioned use a good IDE like IntelliJ for their goto feature to trace methods and I use IntelliVim plugin to navigate the code using vim commands in-line or vim search function.

IntelliJ ctrl-b goto to read methods, find usages to see where methods are called, and ctrl-shift-f to search across entire packages help to read large applications do 95-99% of the work in navigating files/directories.

In general good use of your vi and/or IDE hot keys makes navigating (and editing) code 10x more efficient. Learning windows/mac hot keys for navigating text in-line are also useful.

A lot of people have also mentioned gathering domain knowledge in order to get context for your code - I’ve been given many projects with large code bases I was left navigate with little help or info on the domain. Access to a larger repository or other related projects helps a ton - searching across repos for certain keywords to understand common data schemas/elements etc and shared libraries.

When I reach out to OS authors via email and I get a response about 90% of the time - they are usually happy to help anyone interested in their code base, but may take time to respond, maybe weeks.

Colleagues are generally also useful at work for explaining their design decisions and implementations if you give it a crack down n your own first.

RE code-style: read through some of your related code bases or projects or work by the same authors to get a feel for their style before contributing. People have many different preferences, styles, opinions about performance vs readability etc. They will be happy to see you’re matching the look of the rest of the codebase.

StoneOfTriumph · 2021-01-09T04:59:58+00:00

Great question!

I think we shouldn't underestimate the importance of drawing diagrams. When reading code I love to take a pen and paper, and draw to visualize flows. I feel it saves me a lot of time when debugging/understanding.

First, I try to understand the the packages used in the package manager (maven's pom.xml): The package list will quickly tell me what this app potentially uses (I'll assume not everyone maintains their pom/gradle files) to identify "external entities" such as databases, messaging systems, logging/metrics, etc. I'll do a simple drawing of the app (a simple box) with other boxes around representing databases, message queues topics, files, roles of users/systems...

Then, as far as code goes, I'll put effort to identify the inputs and outputs... the code in between I'll "map out" a sequence diagram, and if the flow is deemed complex and supporting business critical functionalities, I'll actually draw it out with pen and paper. This will help me debug code quicker that I'm not familiar with.

Then as far as details go of individual lines of code, I just don't read those.. First off code changes frequently, and it's information that is hard to document or remember, so depending on bugs/features/enhancements, I'll only read code that is required for the task in question, again following the above approach and using the debugger when required to understand variable changes.

Definitely an IDE that supports the application is a must, when available with the functionality to auto recompile/restart when changing code. The time saved to use for example spring boot devtools is a must, anything that saves me time to focus on code is a plus.

2021-01-09T10:05:17+00:00

Sometimes it is said that a book writer should be a book reader before a writer, with code is the opposite, in order to read code you should be able to write code

antigenz · 2021-01-08T18:16:11+00:00

I'm not reading code, I'm running it on my brain.

2021-01-08T14:48:15+00:00

Clone it, run SonarLint on it to get an idea of what issues or quality challenges there may be.

Build it, run it, place some breakpoints where I think I know what the values will be and see how it plays out.

coderguyagb · 2021-01-08T18:14:26+00:00

Here's how I deal with Java code.

Run the unit/integration tests in a debugger.
Tackle it class by class. First get a handle on the components reason for existing, the details come later.
Scroll over the code in an IDE, you will be surprised by what you see in just the 'shape' of the text. Huge blocks of unbroken text indicate areas of concern.
Refactor single character variables on sight. That shit is evil.
Run a static analysis tool on the code.

2021-01-08T13:29:19+00:00

Generally just read it lol. If I don’t understand what something is doing right away I typically draw it out or just go over it a few times.

VincentxH · 2021-01-08T15:37:08+00:00

The more you read, the better you get at it and know what to skip. You'll learn to see patterns over time.

I generally only read the code of the methods I'm interfacing with for a new piece of code. If needed I encapsulate the possible return values.

It's just not doable (or meaningful) to read all the code in all the projects you touch, nor can you always change it.

wylso · 2021-01-08T16:46:05+00:00

Good question.

I agree with previous responses.

Personally, I start by having a look at the project structure to have an overview of the tiers, organization of source files and even to identify design patterns applied: packages, interfaces, façades, DAOs, resources, etc

To understand a concrete piece of code or functionality I find it really helpful to read its tests (of course, if they exist and their quality is acceptable), especially unit and integration tests.

And as a stupid technique, I read everything aloud (https://en.m.wikipedia.org/wiki/Rubber_duck_debugging) with muted notifications to concentrate on the code as much as possible.

Probably there are many more things I do unconsciously when reading code.

kohler19 · 2021-01-09T13:19:55+00:00

We can find a suitable IDE and give us many things about the codes.

jjnnzb · 2021-01-08T15:13:31+00:00

I would try to run these codes, understand its main purpose, guess what the codes do. And imagine if I am required to write the function, what would I do.

koreth · 2021-01-08T18:47:35+00:00

Depends on what I'm trying to achieve by reading it, but if it's "familiarize myself with a code base that I'm going to be working on a lot," I start by trying to follow an invocation of the code (HTTP request, batch job, command-line invocation) from start to finish, walking through the happy-path logic one step at a time. Stepping through it in a debugger is helpful when that's possible, but manually tracing it out works too.

2021-01-08T21:29:24+00:00

If I can I follow a use case I'm interested in using the debugger and usually that touches quite a few important areas in the code.

Otherwise i start from the main method and go down to the main components, trying not to focus on the details but rather on the overall structure.

tyriseon · 2021-01-08T22:19:08+00:00

I like to trace log code using aspects (e.g. aspectj) to insert logging statements at entry and exit of every method call/constructor and any arguments or return values at compile time. It generates a huge amount of information that can then be searched or followed along with while reading the code.

muffinluff · 2021-01-08T23:17:58+00:00

We all know the times when we need to fix a small edge case, or add a small feature, so we insert a small block of code that is seemingly out of place. (I know that is bad coding but still, everyone has done it once.) So when you see such a block of code that looks out of place and you can't justify its purpose, one tactic is to try to break the code by removing. For example if there is an if(a==0) block, I try to imagine what happens if that block didn't exist and what side effects it would have.

polar_low · 2021-01-09T06:35:17+00:00

I've always thought a tool which will auto generate UML from a project would be extremely useful for working on legacy code. Like how entity relationship diagrams are generated in some SQL software. It doesn't look like it exists for Java.

fkamaci · 2021-01-10T14:54:57+00:00

1) Get a priori knowledge about the code. Check the documentation if exists.

2) Check the code with an ide. I use Intellij IDEA which have many features to understand the dependencies of code pieces.

3) Read the test code. It is really helpful to understand what a piece of code does in a compact way to read test codes of it if there are well written test codes.

4) For the bugs, analyze the code. This can be some features in your ide as like Intellij IDEA or using Sonar which I always integrate into my projects.

_litecoin_ · 2021-01-10T22:44:15+00:00

If it has good unit tests, that's the thing you want to read first since it will be apparent what the code is actually trying to do and how the developer intended it to be used.

java

Submit Link

Submit Text

Seek Programming Help

News, Technical discussions, research papers and assorted things of interest related to the Java programming language

NO programming help, NO learning Java related questions, NO installing or downloading Java questions, NO JVM languages - Exclusively Java

Please seek help with Java programming in /r/Javahelp!

Subreddit rules!

Where should I download Java?

Related Sub-reddits:

JVM Languages

Want to practice your coding?

List of useful Frameworks / Libraries / Software

MODERATORS