He set his window size to 640x480. 320x240 is simply 1/4 of that (half of each dimension).

Well, if you know the size of your window, you can roughly approximate where a coordinate is. The top-left of the screen is (0,0) and the bottom right is (width, height). You will have to experiment with values a bit if you want precise placement, but it's really not that hard.

In 3d games, you're never using hard numbers, its all done with calculations and crazy wizardry.

If you don't know the size of your window, there's always a function to find the size of your window, so that shouldn't be a problem. If you can't do that, assume you have a 2x2 window, and do your best to get your point across using that.

Don't worry about 3d games right now! I've been programming for a couple years now and I've never tried anything 3D. I remember one time I looked at some code of a 3D engine, and I realied it's WAY past me, both programming wise and math/physics wise.

Making games isn't THAT hard, you just need to be a good problem solver, and be persistent enough to keep trying until you finally get the result you want. Oh, and you should know the basic syntax of your language, how to draw stuff to the screen, and how to recieve input from the user via mouse clicks and key presses.

3D engines aren't as hard as they looks, it's more of a matter of wrapping your head around converting 3d to 2d. Once that makes sense, they're no different. Imagine, people use 4 dimensions sometimes when programming in 3d

As for the graphics, it's not really hard, just very, very time consuming if you hard code everything. In most cases, you can use sprites or pictures for everything, the only thing you need to hard code is menu screens and HUD interfaces, which are much simpler.

They absolutely use level editors. Once you have an engine, the editor can be built on top of it relatively quickly, especially compared to coding the levels by hand.

Teams will usually choose one standard and will expect all programmers on that team to stick to that standard (usually the first one you listed, though there are tons of variations). The most organized teams will have some established way of having the computer format your code for you.

The last example you listed is usually frowned upon and may be used only because it neatly fits on one line, which is important in (for example) presentations with limited screen space.

I think the most important thing about coding styles is to decide on one style and stick with it. Consistency of your style throughout a project is much more important than the style itself in my opinion.

I'd also like to add that if you're working on someone else's project, you should try to follow their style as much as possible, again for consistency.

Well, think about how each variable is used. Are you only using a certain variable within a certain method? If so, make it local. Is it used across the program? Make it global. It should only be global if it needs to be imo