To The Other Noob Programmers Out There...

[bzar]

Don't worry too much about correct practice and crap at the start.

It's much more important to get something done. Don't be a code nazi.

You're right. It's much more important to keep the momentum by getting things done than worrying about coding style issues. Coding style evolves with the programmer and good practices should be learned after the basic understanding of the problem and at least one solution are clear. I guess teaching at those two elementary programming courses at my university left a mark on my teaching priorities . The objectives in school programming and hobby programming are totally different and I forget that sometimes. Please continue

 

[Sphinxter]

No I heartily disagree, you focus on correct practice and crap from the very start so you don't code yourself into a corner and people will enjoy reading your stuff and helping you. Later you won't even have to think about it and have a bunch of filthy habits to unlearn.

 

[Butterman]

No I heartily disagree, you focus on correct practice and crap from the very start so you don't code yourself into a corner and people will enjoy reading your stuff and helping you. Later you won't even have to think about it and have a bunch of filthy habits to unlearn.

Maybe if you're doing a comp sci course.

But that stuff puts off begginer hobbyists. You really just have to get in there and make something. Otherwise you're going to spend hours making this beautifully coded program that displays a .BMP file and say, hey fuck this I'm going to go jack off to horse porn.

 

[Kurupted_Magi]

... Huh...

Anyways I can see both sides of the story. I have tried to maintain a balance. Work on my HORRIBLY coded RPG that is fun, and do meaningless, structured programs on the side. The main problem I have is I can be a slow learner. I like examples that really spell it out for you and most times I receive a block of code that looks completely foreign, with the one thing I asked about crammed in the middle, and I have no idea how the rest of the code affects the one thing I asked about.

 

[dflemstr]

No I heartily disagree, you focus on correct practice and crap from the very start so you don't code yourself into a corner and people will enjoy reading your stuff and helping you. Later you won't even have to think about it and have a bunch of filthy habits to unlearn.

Actually, +1. Or, +1000 actually. If you learn good practices from the start, you get these benefits:

• Most good practices come from other programming languages (→ They are generally an effort to compensate for the faults one language has by making it more similar to another language). E.g., C++ "const"s come from concurrent languages like Erlang and functional languages in general, or C++ "template"s and correct usage related to them come from any other language with *real* type parameters.
  So, my point is: If you stick to the best practices, you'll have an easier time learning new programming languages later (and you'll think "Ah, *that* is why I used arrays of function pointers in my C program instead of switches").
  
• You can extend your program very easily. What if you don't want a "list of entities" à la @timbobsteve, but instead need a scene graph? Is it wise, then, to build your main loop using a for loop that walks through all entities, or should you use a visitor pattern to begin with? (This was a bad example because a list of entities works pretty well actually)
  Or, is it wise to use a global list of entities; what if you want to be able to run your game in 2-player-mode and need 2 sets of entities? Why not keep the entities in a class that gets passed around? Or, why not use singletons?
  
• The code becomes more readable. You'll less often do small "hacks" that make the code work (like adding a quick little "position.x += 1" in your "draw()" method instead of your "update()" method), and such hacks make the code unreadable.
  
• The code has less errors. If you stick to standard patterns, you can rely on them working most of the time. Less time at the debugger.
  
• The code often becomes more efficient. This is a no-brainer. At the beginning of my "programming career", I used to use some kind of variant of insertion sort for sorting my stuff. When I discovered qsort... man, that was awesome. My app became around ten times faster.
  
• People will want to help you. If you post on a forum saying "Help, I need to know an efficient way to put this depth-sorted Z-ordered tree of sprites onto the screen by eliminating overdraws" instead of "Help, I want to draw a guy on the screen; I have images for all of his 10240 pose, weapon and walk combinations", you'll instantly get much better answers.
  And people will understand your code without having to ask which globals are defined, what "wrt_Xpos_designOffset_color" means, and why the heck you're calling "glutSwapBuffers" three times in a row.

 

[Kurupted_Magi]

Is it wise, then, to build your main loop using a for loop that walks through all entities, or should you use a visitor pattern to begin with? (This was a bad example because a list of entities works pretty well actually)
Or, is it wise to use a global list of entities; what if you want to be able to run your game in 2-player-mode and need 2 sets of entities? Why not keep the entities in a class that gets passed around? Or, why not use singletons?

People will want to help you. If you post on a forum saying "Help, I need to know an efficient way to put this depth-sorted Z-ordered tree of sprites onto the screen by eliminating overdraws" instead of "Help, I want to draw a guy on the screen; I have images for all of his 10240 pose, weapon and walk combinations", you'll instantly get much better answers.
And people will understand your code without having to ask which globals are defined, what "wrt_Xpos_designOffset_color" means, and why the heck you're calling "glutSwapBuffers" three times in a row.

This is exactly the kind of stuff I am referring to =P

 

[Tempel]

There's a tradeoff being discussed here. Really, anyone serious about programming should follow best practices, for all listed reasons. But there's the psychological issue for new programmers (or sometimes even old hands) who need to get feedback to stay motivated. This is true in any education. My recommendation: new programmers, start very small (like, smaller than a game), try to consider best practices, but mostly just have fun. But, as your projects get bigger, best practices will become more important, so try to pick them up as you go.

I'm only an occasional programmer, so this is mostly what I do. I've spent days agonizing over design decisions, only to spew some expletives then hack together whatever garbage code that works. It's ugly, unreadable, and inextensible, but it gets the job done and is extremely gratifying. Eventually, I get back to clean it up, rewrite the whole thing, and am a lot better off for it.

 

[trooper]

Ok, A lot of people suggesting to follow good programming practices from the start, From where ?

I pretty sure it`s like most things, Everyone has their own ideas and opinions of "good practices".
Looking at some of the responses i have read on various forums, Everyone has their own way of organising,
structuring and planning their projects, Code etc. So, Us newbs run the risk of picking us someone else's
bad habits. As there is really no definitive way of doing thing correctly.

Take driving for example, Everyone gets taught the basics when taking their lessons, Then they are assessed
on their abilities once they reach the dreaded test. But there on after, They are pretty much on their
own with regards to approaching difficult, Or situations not covered in the lessons.

I am a programming newb, As in, The only real programming experience i have is writing from scratch,
A basic mastermind game in SAM BASIC about twenty years ago, Using only the user manual it came with as a guide.

I have only just started to follow the Lazy Foo tutorials (Once i had found out how shit Vista is, As the first
piece of code in said tutorial would not compile, No matter what IDE i used, But worked fine in WinXP and Win7),
And can see a long and quite difficult journey ahead getting to grips with the basic`s, Let alone what
everything does (Keywords, procedures etc (or what ever they are called in SDL/C++)), Or even how best to organise
things. :blink:

Where do we learn these "good practices" and from whom ?.

Newb programmer

Trooper

 

[Kurupted_Magi]

That is a very valid point/question. Unfortunately, I do not see an answer to that. Best practice seems to always end with OOP being the only reply.

This is why I was hoping to find a few other newbies around here to start programming with, as I believe there will not be many better ways to learn a tolerable coding structure, best practices, and general learning than when working on one piece of code with two or three other beginners. I have gotten some interesting feedback on this post, though I still intend this to pull in some other newbies that would like to learn with someone. - Magi

 

[Sphinxter]

No I heartily disagree, you focus on correct practice and crap from the very start so you don't code yourself into a corner and people will enjoy reading your stuff and helping you. Later you won't even have to think about it and have a bunch of filthy habits to unlearn.

Maybe if you're doing a comp sci course.

But that stuff puts off begginer hobbyists. You really just have to get in there and make something. Otherwise you're going to spend hours making this beautifully coded program that displays a .BMP file and say, hey fuck this I'm going to go jack off to horse porn.

Maybe it's all for the best you go jack off to horse pr0n if you think it's not worth doing right, you'll certainly be a lot less frustrated that way.

On Object Orientation:
If ++ syntax is overwhelming and it can be very start out in C and build on it with structures as objects. Write black box functions with only one entry and only one exit point, pass those objects, stay away from declaring variables outside of them globally as much as possible and create a separate module for every object of functions that manipulate it plus a header file that defines the object both of the same name, think of it as just staying organized because after all neatness does count. If a module hits 2500 lines start a new one, don't copy and paste, create a utility module of code you find repeating itself and call those functions in it instead. You can do a well written SDL program in about 20 lines to display that .BMP file, nobody said you have to re-invent the fucking wheel.

OOP is a state of mind, you apply the model regardless of the tools, I even write object oriented shell scripts. Stick with it and you'll find yourself almost never having to use a debugger because you simply won't create any. There are some very good reasons for it besides not creating a buggy nightmare like being able to re-use those modules instead of writing the same thing over and over. The lazier the programmer the more object oriented they usually are.

 

[wardred]

A good class for a lot of people helps. You get feedback and you're given deadlines...finding the good class can be a chore.

A decent book helps too - so far the c++ primer V. 5 seems to be working well for me as a recap to the language. Then books. Then a library.

If you have *decent* practices, but get stuck on particular problems, then forums, IRC, etc. can help.

 

[wardred]

And, hey, for motivation to get a project done, there's that wacky Pandora Angst contest. http://webpoint-servers.com/pacc/ I intend to turn something in there. It's a personal project, and that thing gives me a deadline. Coded properly it should be a snap to port to the Pandora.

Cheers.

 

[senquack]

Any time someone says "I have a good understanding of C++" you should look at them with somewhat skeptical eyes unless they look like this man.

I'm not saying C++ is a bad language but it is powerful, convoluted, filled with nuance, and hardly intuitive. I would highly suggest starting out with C. It is not the easiest way to start but it is, I think, the best way if you are serious about programming. If you are not so serious about deeply understanding programming and are more happy approaching it from a casual, more productive, fun angle I would suggest something like Python or some other scripted high-level language if you are programming for a Unix OS like Pandora's or the Wiz's.

I am not the most experienced programmer in this thread, probably not by a long shot, so take my advice only if you like

 

[bzar]

No I heartily disagree, you focus on correct practice and crap from the very start so you don't code yourself into a corner and people will enjoy reading your stuff and helping you. Later you won't even have to think about it and have a bunch of filthy habits to unlearn.

What I mean is that with hobby programming you can get results first, then good results. With school programming you need to get good results immediately. Making headway keeps the motivation up. Getting something work at all might provide just that motivation required to find out how to do it right and reimplement.

When I dive in to a new topic (language, library, framework, etc...), I usually start by hacking something together with no regards to practices to get a hold of the concepts and how they work together. When I'm reasonably comfortable working with them, I look up best practices. This way I can actually understand WHY they are considered best practices as opposed to just following a dogma. Afterwards I look at my earlier hacky code to see where and why I made the bad choices I did. Then I reimplement using best practices. In my experience this approach has the advantage of quicker results, faster and deeper learning of the subject and increased motivation. This approach is not an option in school programming where time, resources and learning objectives are limited. There it's better to stick to teaching dogma first, then let the understanding come later.

 

[timbobsteve]

This is why I was hoping to find a few other newbies around here to start programming with, as I believe there will not be many better ways to learn a tolerable coding structure, best practices, and general learning than when working on one piece of code with two or three other beginners. I have gotten some interesting feedback on this post, though I still intend this to pull in some other newbies that would like to learn with someone. - Magi

I'm all for that. I've never really been part of a group project, so I'm pretty much oblivious to working on code within a group. I'm sure coding as a group comes with some pretty large problems, especially for newbie coders, so it would probably be better to get a mix of beginner and experienced coders on board, just so the new can learn from the old A fine example of this would be... who decides on the engine structure and modularisation of code? If a beginner was asked to do this, I'm sure we'd probably go about it in a slightly backwards manner that would make collaborative work hard. This is where an intermediate or experienced coder would be handy. They could say stuff like "OK... we'll separate the rendering code and the game code into [these] parts and the objects will be handled like [this]". Then the newbs can be handed tasks, or take small tasks and go away to do their part. Mind you, this whole scenario is based around a BIG project. Something like a 2D sidescroller can probably get away with 2 coders at max + artists, otherwise it could get crowded.

RE: Coding Practices

I agree with everything everyone has said on the forums so far. Coding with good structure in mind saves many many headaches later on and allows anyone to pick it up and assist/fix/debug should the need arise. I also agree that hobby programmers like to get stuff done and have something to show their friends/family. I guess as a beginner starting coding as a hobby it is best to get a subtle mix of both ways of thinking. I try to do this, which is why I keep asking everyone if I'm attacking problems in the right manner People keep giving me feedback on code structure and problem solving which helps both ways.

 

[proflogic]

What I mean is that with hobby programming you can get results first, then good results.

I think the important part is that those first results are small. Newbies to programming/software design should try for smaller goals that are still fun; otherwise, that big, interesting project you're planning is likely to become a big mess.

On languages, I don't recommend anyone start with C or C++. When you're starting out, you have a lot to learn. Adding machine structures and pointers on top often increases your bug rate tremendously. Higher-level languages like Python, BASIC, or Scheme allow you to focus on the basics first.

I started out making simple games in BASIC (first chipmunkBASIC on old Macs, then on TI calculators during math classes ). In college, they started the CS folk off with Scheme and basic programming constructs (loops, functions, recursion, etc.). Then they move on to data structures, algorithms, and OOP in Java for the second course, followed by machine structures with C and MIPS assembly in the third course. That might be a little drawn out for the hobbyist, but I thought this layered approach provided a good foundation.

 

[foxblock]

About best practices: I also think one should pick these up right away. When I had my lessons on programming in school, we did not care for that stuff, we just had a task, completed it somehow (mostly on our own) and then went on to the next project.
But after you finish that one task you usually have a working, but very messy code and the next step should then be to clean that code up. It's a bloody damn boring task to do, so why not do it right from the start? It will take you some more tile to develop a thing, but in the end you will have fine, readable code, which you can release as open source without giving others headaches.

Also don't mistake best practices in coding and code formatting, with optimisation, that's a whole different story.
My approach on that is like Knuth's: just worry about it later! As optimized code can get more messy and usually a bit longer and unclear it's not very productive to write fully optimized code from the start - you will get lost and probably also loose some code accessibility on the way which you might need later when you have more modules.
So start coding using best practices as much as you can and are able to and then when you have a finished program you can worry about optimisation in case it's necessary.

On languages, well I also can't say I recommend C++ as it is complicated, complex and not very intuitive, but it's the most widespread language and you can get some fine results with it. Also you probably have the most availability of tools, tutorials and people with knowledge which can help you.
Python on the other hand is said to be much more intuitive and easy to pick up, but it's really different from C++.
So you just might start with C++, but start low and try to make your first programs as simple as possible. Try not to use any of the complex stuff there is at first and pick up important things like pointers, arrays (and vectors) and proper use of functions and variables on the way.
In the end you will be able to code something in the code language used in probably 90% of modern games, but it can be a rocky way until then - Just don't get demotivated or in case you do, try to draw some graphics for your game, always helps me to loose some stress and be abl to find some motivation to code again.

foxblock out

 

[bzar]

What I mean is that with hobby programming you can get results first, then good results.

I think the important part is that those first results are small. Newbies to programming/software design should try for smaller goals that are still fun; otherwise, that big, interesting project you're planning is likely to become a big mess.

Yes, this is what I mean. First you get some results quick, then you learn to do stuff right and start on that bigger project when you have your bases covered.

About best practices: I also think one should pick these up right away. When I had my lessons on programming in school, we did not care for that stuff, we just had a task, completed it somehow (mostly on our own) and then went on to the next project.
But after you finish that one task you usually have a working, but very messy code and the next step should then be to clean that code up. It's a bloody damn boring task to do, so why not do it right from the start? It will take you some more tile to develop a thing, but in the end you will have fine, readable code, which you can release as open source without giving others headaches.

It's hard to actually learn best practices when you're still wrapping your head around the concepts they involve. A small test project helps figure the concepts out which in turn allows deeper understanding of the rationale behind those practices. I don't mean you should code an entire software with no regards to practices. Just something to get you comfortable with the environment.

 

[timbobsteve]

I started on C# with C++ being the holy-grail of programming when I was 13. I moved on and did C/C++ on and off for about 7 years now... so I'm somewhat comfortable with it. I've tried using pyGame on occasions because its supposed to be so much simpler, but I prefer C++ syntax and often just get confused and frustrated with Python.

If you don't already know C/C++, then by all means start on Python or BASIC or something else... it's just easier for me to continue on with C++ rather than get put off by the others

 

[foxblock]

It's hard to actually learn best practices when you're still wrapping your head around the concepts they involve. A small test project helps figure the concepts out which in turn allows deeper understanding of the rationale behind those practices. I don't mean you should code an entire software with no regards to practices. Just something to get you comfortable with the environment.

Ok I can totally agree to that.
But as you said, when starting a bigger project you should really worry about such things and most important: Planning (ahead). That's probably the thing I tell all people I give any advice, because I made that mistake several times in the past myself and now think it's very important if not mandatory.
So in case you want to start a bigger project (this does not account for little test games or minigames for let's say PandoraPanic!), plan first and code later. Grap a pen and paper and start writing down what elements you want to have in your game, what should the setting be like, what is the player supposed to be able to do, and most important what type of game is this going to be. Then when you have a list of ideas, go through it again, look which play well with each other and which don't, maybe connect them with arrows, add comments, draw an idea-map (these connected bubbles with the ideas in it) and critically see what's left of your initial ideas and how you can integrate that into your type of game and gameplay (maybe even take a break of a day between these steps).
After you have all your ideas sorted, don't start coding directly, but start drawing class diagrams (UML charts for example). See what classes you are going to need, which properties do they need, where can you make use of inheritance, etc.
None of these figures and diagrams need to be perfect or final, but they can evolve through the process and you should always take a look at stuff you did not read through for a time to update them and keep your ideas fresh.

I know this is a long, tiresome and boring process, but in the end you will have a good list of ideas and game concepts and even some class-charts, which will greatly help you in the process of coding. The reason behind this is to not get lost and keep your code clean from the start.
If you plan ahead what classes you are going to need, you did most of the work already and coding will be easy and quick. At the same time you avoid being forced to use nasty hacks as you won't need to forcefully integrate new game concepts in your network of classes which they don't fir in - as you have planned ahead how to integrate each feature.

Of course you won't be able to plan everything from the start, but try to do as much as you can, the rest will evolve eventually. Just keep yourself from starting to code too early.

But that really does only account for larger projects, not the early test ones (though you can probably test this process, too and find your preferred way of doing it).
I just thought it's an usefully advice worth sharing to novice developers.

foxblock out