I made 4 Java games through my 6 months being a hobbyist game programmer. Before this hobby, I programmed 2 years in Java and a semester worth in Visual Basic and basic C++.

I never thought to practice reading other people's code until now. So when I decided to do so, I found myself unable to make sense of their code.

There seems to be five reasons why.

1) The code is structured very differently than how I would have coded.

2) They used some syntax I never used before.

3) No comments.

4) Code is using concepts and techniques I never used before.

5) Magic numbers

I'm reading an platformer engine coded by someone after having coded a simple arcade shooter game all by myself.

I tried to read Notch's Mario Source code and the way he wrote his codebase is out of this world. His codebase looks very extreme.

I need feedback on how I should practice reading their code.

Splendid idea to try and read other people's code. There's so much to learn from that.

First and foremost I'd try to give myself a task, something to go and find out. For example, find out how he handles collisions. This way, you can focus on your task and ignore anything that doesn't seem related. Otherwise, I can imagine you'd be overwhelmed fast.

Next, I tend to pinpoint some classes that seem relevant to me (just from their names, often) and try to sketch their relationship. If you know UML that's cool, but some simple rectangles for the classes and lines for relationships will do.

Now that you have the structure of the code, it may be interesting to compare it to what you would have done. How is this different, can you think up why it was done this way? Maybe yours is actually better?

When reading code, you may well encounter some syntax you never used before. Hopefully that is something you can google, or otherwise ask here. Most often, this is 'syntactic sugar' and can be written in another way. E.g., x += 2 is the same as x = x + 2.

As of your points 3) and 5): the source code of Notch's Mario is quite heavy on the magic numbers. I think that's the most difficult kind of code to read, because you cannot simply google magic numbers, like you can do with unknown syntax. Maybe you'd be off better trying to read some other game's source?

You'd be better off reading source code to libraries, rather than games. Game code tends to end up being a collection of horrific coding constructs, written in a rush just before the deadline, by people who haven't slept properly in weeks. They've usually beaten the code into something that more-or-less works, often with hideous hacks permeating every pore. Library code on the other hand, tends to adhere to better design principles, tends to have better documentation, tends to concern itself with only one or two aspects, and is usually simpler to understand. Production code is fugly.

p.s. If you struggle to understand someone else's code, 9 times out of 10, it's because their code is crap. (And no, just because the code underpins a commercially successful game, does not mean it has some mythical quality. The code will be crap - that's the nature of code delivered as part of a production schedule)

p.p.s. Related video:

1) The code is structured very differently than how I would have coded.
2) They used some syntax I never used before.
3) No comments.
4) Code is using concepts and techniques I never used before.
5) Magic numbers

Welcome to professional software engineering!

Seriously, if you need to work on a team, this is what most other people's code is going to look like. Ninety percent of code is crap, just like everything else (Sturgeon's law). And, if you're doing something like fixing bugs, or if you tend to redesign features or work on optimizations, there's probably more work to be done in the really poorly designed parts of the game, so you have to read a lot of bad code.

If you can only read well-structured code with concepts you have used before, you are bad at reading code. You can get arrogant about it and maybe even refuse to read badly designed code. Some engineers make a living out of carving their own little software niche and keeping the other engineers out of it. Or, you can try to practice like you're doing - I suggest reading lots of code posted on this forum, even if someone asks a completely unintelligible question about it. Honestly, gamedev.net is a great place to read a lot of really awful code.

If there's syntax you don't understand, or if somebody uses part of a standard library that you do not recognize, that's completely on you. If you've programmed over two years now, I have to ask, have you studied the Java language specification? Have you studied the java docs for the Java API? Part of knowing how to read code is practice. The other part is being very good at breaking down code into exactly what it does, instead of relying upon general pattern recognition. For that, you need to know the standards.

So, my feedback is, really learn all the details of Java. Know the specification, try to learn a majority of the class library - at least enough so that you know, if you come across something new, you've learned so much of the class library that it will be easy to learn more class in a very short amount of time. Maybe even take a peek into the virtual machine specs, once you run out of language details. I wouldn't expect you to retain 100% of all this learning, but after a certain point, you'll be able to go back and reference parts quickly when you don't remember something. Google is ok, but I prefer to be able to go straight to an official document.

1) The code is structured very differently than how I would have coded.
2) They used some syntax I never used before.
3) No comments.
4) Code is using concepts and techniques I never used before.
5) Magic numbers

Welcome to professional software engineering!

Seriously, if you need to work on a team, this is what most other people's code is going to look like. Ninety percent of code is crap, just like everything else (Sturgeon's law). And, if you're doing something like fixing bugs, or if you tend to redesign features or work on optimizations, there's probably more work to be done in the really poorly designed parts of the game, so you have to read a lot of bad code.

If you can only read well-structured code with concepts you have used before, you are bad at reading code. You can get arrogant about it and maybe even refuse to read badly designed code. Some engineers make a living out of carving their own little software niche and keeping the other engineers out of it. Or, you can try to practice like you're doing - I suggest reading lots of code posted on this forum, even if someone asks a completely unintelligible question about it. Honestly, gamedev.net is a great place to read a lot of really awful code.

If there's syntax you don't understand, or if somebody uses part of a standard library that you do not recognize, that's completely on you. If you've programmed over two years now, I have to ask, have you studied the Java language specification? Have you studied the java docs for the Java API? Part of knowing how to read code is practice. The other part is being very good at breaking down code into exactly what it does, instead of relying upon general pattern recognition. For that, you need to know the standards.

So, my feedback is, really learn all the details of Java. Know the specification, try to learn a majority of the class library - at least enough so that you know, if you come across something new, you've learned so much of the class library that it will be easy to learn more class in a very short amount of time. Maybe even take a peek into the virtual machine specs, once you run out of language details. I wouldn't expect you to retain 100% of all this learning, but after a certain point, you'll be able to go back and reference parts quickly when you don't remember something. Google is ok, but I prefer to be able to go straight to an official document.

I just downloaded the java language and virtual machine specification pdf as I just finished reading your post. Thanks for the recommendations!

I do not study API. I just refer to the API whenever I need a method of a class that can make my life easier programming parts of the functionality of a game feature and then I just apply the code. Everytime I need to refer, it is part of the library I never used before.

Okay I am going to read code(good or bad) as practice.

Unfortunately, I never worked in a team before. I never have a friend or even heard of anyone in my college who actually made a game before. I had to teach myself.

Seriously, if you need to work on a team, this is what most other people's code is going to look like. Ninety percent of code is crap, just like everything else (Sturgeon's law). And, if you're doing something like fixing bugs, or if you tend to redesign features or work on optimizations, there's probably more work to be done in the really poorly designed parts of the game, so you have to read a lot of bad code.

Yes, and No. Imho there is a difference between reading through code for a game (found online, from unknown author), and the code of a fellow team member, and that's the ability to ask stupid questions. With any luck, on a team you'll be sticking to a standardised coding convention, so hopefully the code should adopt constructs and a style that is known to you....