Techniques or essentials skills required to read other persons code [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

Currently I have started on very large Legacy Project and am in a situation which I always feared Reading and Understanding Other People's code, I have known that this is an essential skill which is required but haven't developed it as till date it was not required and now its like开发者_JS百科 necessity to develop this skill rather than hobby and so I would like to know from SO Readers about:

1. How you have overcome the hurdle of reading other people's code ?
2. What techniques or skill have you developed to polish your art of reading and understanding other people code ?
3. Are there any books or articles which you have referred to or in general how did you developed the skill of reading and understanding other people's code ?

I would highly appreciate useful answers to this questions as now I can understand how one would feel while trying to understand my code.

---

Practice. Practice. Practice.

I overcame the hurdle by interacting with people on open-source projects. Discussing my contributions with others, and seeing their suggestions and ways of looking at things really opened my eyes.

I suggest you find a project that fits you, check out the source and contribute what you can (no matter how small to begin with). Over time the skill of reading code should just come naturally. Some projects even offer mentors specifically for helping out new contributors.

---

Michael Feathers' Working Effectively with Legacy Code is a great resource that contains a large number of techniques for working with older code.

---

Practice, Practice, Practice.

If you can, talk to whoever wrote the code or has an idea about it. Draw lots of pictures and have them explain big things to you while YOU write comments.

The quickest way to find your way around is to get lost. Dive into the code and break stuff. See if you can change an int into to a string or something.

---

Patience: Understand that reading code is more difficult than writing new code. Then you need to respect the code, even if it is not very readable, for it does its job and in many cases pretty efficiently. You need to give the code time and effort to understand it.

Understand the Architecture: It is best if there is any documentation on this. Try talking to people who know more about it if they are available.

Test it: You need to spend some time testing and debugging the code so you know what it does. For those parts you understand, write some unit tests if possible so you can use them later.

Be Unassuming: Many times the names of the patterns are misused. The classes have names which do not indicate their purpose. So don't assume anything about them.

Learn Refactoring: The best book I found on this topic is Refactoring: Improving the Design of Existing Code - By Martin Fowler. Working Effectively with Legacy Code is another awesome one.

---

I don't know of any way to do it, i have participated in several proyects, where i have to undertand by my own, how do they think in and achieve that solution, so i can undertand it too.

That's why every time i can, i recommend, if you are a developer, try comment the code, all you can, because, you don't know if someone will find it useful (i think i make my point)

If you're not a developer, you should find someone to support you.

---

How do you learn to read what other people have written? You get really good at writing yourself and try to make sure the person is as good a writer as possible (suggest things they could do better, like adding some darn comments) Sadly, code is almost always read by someone else other than the author. Practice, and familiarity with some of the person's other code can help. But whenever you spend over 5 minutes figuring out what a particular line means, note how they could have done it better, and make sure you never make the same mistake.

good luck. :D

---

When I'm approaching an unfamiliar code base, I like to start at the beginning. Find main(), and write out a summary of what main() does. Create a list of the functions/methods called in main(). If you're visual, create a flowchart of main().

Once you have a list of the methods called directly from main(), look up those methods and repeat the process. As you figure out what each of those methods is doing, write it up in JavaDoc format and paste it into its corresponding box in the flowchart. If it's an API call, document which API it is using and put a link to the relevant API documentation.

Working recursively, you will create a map of the application and figure out what the program actually does. Once you know what it actually does, you will be able to find inconsistencies between what it does and what it's supposed to do.

---

The answer varies depending on the tools and documentation available. If any documentation is available, I try to understand the high level overview of the system - the different modules, interfaces and subsystem interaction. This helps to divide and conquer the code into sizable pieces as you go along reading the code. If any design patterns are commonly used across the code try to build up your knowledge on that. Also depending on the tools available I may use any of the popular source code browsers (Source Navigator/Source Insight) to quickly view the dependencies (class hierarchy etc). This speeds up code understanding. Also if I have some handy unit testing framework try playing with the code- different inputs and expected output. I also recommend using debugger to step through selected complex functions to get a hang of the code flow.