Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)?

Someone reading what you coded on your first job

share|improve this question
    
You become assimilated. You become part of the One. –  Thomas Eding Sep 26 '12 at 16:46
1  
I have to say that in a professional setting, you are generally going to be fixing the broken parts which tend to be the worst parts of the code. My experience is that it's almost always like your cartoon. If you are fortunate enough to work somewhere that software quality is critical to business success - and the company appreciates that - then your experience will be much better. But fixing bugs and extending things inevitably leads you through the worst parts of any code base. –  GlenPeterson Sep 26 '12 at 16:53
add comment

3 Answers

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.

share|improve this answer
9  
+100 for "the less I question the competence of other programmers". I think the sometimes present "clearly an idiot wrote this" attitude creates an environment where newbies are scared to ask questions (or "non-idiots" don't question their own practices enough), which in turn leads to bad code. –  Timothy Jones Sep 26 '12 at 4:10
1  
@TimothyJones You realise that it is actually possible to award +100, by way of the bounty mechanism? –  David Wallace Sep 26 '12 at 4:46
1  
@DavidWallace I'd forgotten, thanks. However, then I won't be able to comment any more. Perhaps I will come back and do it when it's not all my rep. –  Timothy Jones Sep 26 '12 at 4:54
2  
The worst is when you say, "Clearly an idiot wrote this" just before you realize that you are looking at your own code! –  GlenPeterson Sep 26 '12 at 16:45
    
@GlenPeterson, No, I'd say the worst is when the one who wrote it stands right next to you... –  Svish Oct 16 '12 at 9:04
add comment

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.

share|improve this answer
1  
Haven't seen that cartoon in ages. Thanks! –  Andrew Sep 26 '12 at 16:43
add comment

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:

  • Refactoring the code.
  • Choosing a feature to add that requires going into the depths of the code.
  • Writing comprehensive unit tests for the code.

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.