When reading others code do you usually have any troubles understanding it, Or its more usually that you question the others code about it being wrong/non-efficient/bad-formatted(etc)?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as unclear what you're asking by MichaelT, Bart van Ingen Schenau, mattnz, jwenting, Kilian Foth Jul 14 '14 at 10:14
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.
These days I don't have much problems reading other people's code. I've seen so much bad code, that I can even diagnose what sort of evolution led to any I find.
More often than not, professionally bad code is code that started out okay, but best practices, requirements, or skillsets moved out from underneath it. Sometimes it is just someone who is bad or new to the language, but that's pretty apparent too (and uncommon in a professional setting). The more I understand why code rots, the less I question the competence of other programmers.
This may be the result of this development process.
In the last 2 years I have working with other people code. I have debugged it, fixed bugs and made improvements. In my experience I usually think that the code is bad, full of bugs, slow, consumes much more memory than needed, used programming concepts inappropriately, really bad formatted (this is hard to live with), not commented and the logic flow is a mess. What if I tell you that I found one function with 5k lines of code?
So in my experience I usually question the quality of code. If something is hard to understand, because it is complex, it make sense after you understand it. But if it is just bad it will always be bad.
Short Answer: Mostly we don't like it or get very critical on why coding is done this way, and not the other way around. However, more you read other's bad code, faster you appreciate well written code :)
Although it may sound obvious but the best way to get better at reading people's code is: by reading people's code. The problem is that when people typically read other people's code they don't try to "grok" it, i.e. become intimately familiar with it; they do the equivalent of speed-reading poetry.
To grok someone else's code you may try the following:
All of these steps will force you to read the code in greater depth.
There are also some tips how to maximize the understanding of a code-base, that you have been introduce for maintenance and support:
Once you have a basic idea of what's going on, you may want to take a good look at the data storage (the persistence layer). That's another great way to get an understanding of what's happening, but make sure the things you are studying are actually in use. I can remember a few times really getting to the bottom of some classes with this approach, thinking I've understood the system - and then realizing later the classes weren't used at all.
It may seem like a daunting task - it does take time and no fancy tools can remove the need for intelligence - but it can also be very rewarding. As you go, you will probably find a lot of bugs in corner/edge cases, and see ways to improve the code. One piece of advice - don't go too heavy on refactoring / changing until you have a good understanding of the code. Often what looks like a mistake or just plain bad code when you first see it, turns out to be subtle genius at work upon later, enlightened investigation. Also, removing unused code is so satisfying, and great for any future maintainers. Of cource, with the assumption that all code base is version controlled.