Reading source code

If you are reading other people's source code, how do you approach the code? What patterns are you looking for (data types, loops, use of control flow, ...)? How long can you read other people's code without being bored? What are the most exciting patterns you've discovered so far?

+4
source share
6 answers

In addition to the obvious general “work from above” approach, it depends on why . I am reading it: code review, trying to understand some available code for adaptation for my own use, trying to learn a new technique, etc.

It is also highly language dependent. If this is OOPL, I will probably do something like this:

  • Look first at the relationship of the primary class and try to understand the primary responsibility of each class.
  • Look at the interactions between classes to see how they interact.
  • Look at the key class interfaces to see what “services” they offer to their employees.
  • Look at non-trivial methods if it’s important to understand how they work instead , for which they are responsible.
+1
source

At first, I ignore the desire to change the code. This is sometimes difficult to do. But understanding at first and change later saves itself from many unpleasant "experiences."

Next, if the format is bad, reformat. Use a code formatter if you have one. This is because you tend to look at the indentation, and if it's bad, your understanding of the code is also in doubt.

Then, if there are complex data structures, I like to draw a small chart. The task here is as simple as possible. Large charts are funny on the wall, but in most cases they are cumbersome to watch. So it is wasted.

If you finally understand what a piece of code does, write a comment. This is important because otherwise you will not understand it the next time you are here.

The next step is to create unit tests. Now you can not only test the code, but also test your understanding of the code.

Finally, if you understand this, and know that it can (and should be) better, change it. But be sure to run the tests. If you are not paid for every error you solve.

+8
source

The new term for this type of Code Spelunking .

+3
source

thanks, if I understand correctly, the first step is to define the context, the second to identify the API and put the API in the context. I just understand that this is like viewing a building or a work of art, you can focus on the material used or the function of the parts, try different perspectives, judge how the details fit into the whole ... there is a nice piece of the discovery process: here - as they think mathematics

+1
source

It all depends on what type of code you are reading. Is it a web application, service, desktop application? When I start reading other code, I usually start looking for design patterns. Or for frame things. But then again, if you are doing a review. If you read for your own interests and learn something, there really is no answer - you must carefully read and understand the code.

0
source

Select the element that you understand in the final product, and see how it folds. If you have unit tests, then this is a great help.

0
source

All Articles