We will look at correcting the format, but we wont make any apollogies for publishing a tutotorial writen by somebody who hasn't done any programing like this for almost 30 years until a device like the RasPi came along to re-awaken his enthusiam, and other tutorials like Liams gave him the confidence to start writing something like this himself.
You don't need to make apologies as I am glad you published this tutorial. I tried to explain as clearly as I could, what could you do better and how. I understand very well that it's not easy to write a good tutorial. I also understand there's a lesson in every failure.
Please, keep publishing everything you get! Especially the things you think that failed. It's important to keep going. That's one of the best ways to get better.
For those who dont know this game was based on Liam Frasers RasPi shooter examples, even though they dont look anything like each other now. This is exactly how I learned to code, I didn't write a masterpiece on day one, I just modified other examples to make small changes one at a time.
Thousands of text book have been available over the years on creating the perfect code, but in my opinion these prescriptive guides have contributed to lots of people being too afraid to try and pick up coding, and NOT becoming interested in IT, the learning curve is just too steep if you aim for "perfect code" on day one.
I think we should be telling people it's ok to make mistakes, it's ok to have four or five levels of indentation or structure if it means you learned something you would otherwise not had the confidence to try.
"trying to write perfect code from day 1" or "trying to write perfect tutorial from day 1" isn't a steep learning curve - It's a rocky Mount Everest of learning curves. I very well know this.
Think about this: If you succeed writing a good tutorial for raspberry pi, it'll encourage more people to take on programming. That's what I want and I tried to help you by pointing out the major things you can improve at the moment.
The indentation rule is about complexity and not repeating yourself. It's not always good idea to break deeply indented code into smaller chunks, but it's an indication that you're packing too many concerns and variables into single piece of code. Divide and conquer you know?
I think these examples are just the kind of thing that Liz, Eben and the other members of the foundation were hoping to see people create, so in that sense I think it's a win, and every person that does find it useful is one person that is getting exited about IT that we might otherwise have lost.
Count me in to that list. I'm all for getting the Pi in the sky even if I'm not a member of the foundation. I have couple very good reasons to support Raspberry Pi foundation.
I'll try to be less harsh with subsequent appraising. I really want you to do what you're doing right now. All of you.
Cheery, any chance you would like to write some articles about good programming practice, defensive programming etc for beginners, I"m sure it would be really helpful for others to learn. I"m sure if they are good, then Frambozenbier will be willing to feature them, as would the MagPi.
The same offer is open to anyone else too, just to be clear.
I've been busy with other things.. But I'll try to get on writing couple tutorials myself as well. Expect me to fail couple times though! Even if I've been coding for a long while now, I don't think I would write the best tutorials around here. Antiloquax is one step further me on this matter right now, as he has published his first tutorial.
Cheery: We would love to have more info about best practice and good habits to go alongside the "new user" content, so if you write it, we will post it. I'd be happy to create a new section for "coding style" and "error trapping", or give you your own section on the site to share your experiance and skills.
People will always do errors when they start. An excellent training material might help them point out those errors and solve them, or even give them an idea of how to figure out the errors they do on themselves. Whenever you're doing something, you should understand well why you are doing it. You sort of do not have "best practices". You pick them along while you are doing.
That paragraph is a start. I'll try share more whenever I can.
Well, I am wishing now that I had spent a bit more time on the code and the text description before passing it on to Frambozenbier. [hangs head in shame]
I will try to revise the whole thing as soon as possible and re-submit it!
Don't be sad about that thing. Keep doing and I'll reward you again.