PureBasic Forums - English

Heres a quotation from Albert Einstein which I think sums up my philosophy when it comes to coding;

"Keep on sowing your seed, for you never know which will grow - perhaps it all will."
Albert Einstein

Unfortunately it all doesn't
But I'm hoping some of it will.

Whats your philosophy?

Tell Netmaestro you have an impossible problem to solve and that he couldn't possibly master it, sit back with a mug of coffee and a newspaper and await the code!

I have erm 'written' 150000 lines of code that way!

srod wrote:Tell Netmaestro you have an impossible problem to solve and that he couldn't possibly master it, sit back with a mug of coffee and a newspaper and await the code!

I have erm 'written' 150000 lines of code that way!

My philosophy is to assume that I will need to edit the program in a few months time therefore I must prepare for this at the time of writing the program. Amongst other things, this means including meaningful, helpful comments that don't merely paraphrase the code.

Also, (though this is probably more of a strategy than a philosophy) on first writing a program, before working on it's main logic, I initially focus all my efforts into producing a good, functional graphical interface (GUI) because it tends to make debugging much more meaningful as the context is then correct. It also enables a program demo/simulation to be rapidly available, if required.

P.S. I know what KISS means, but what about STRiP? This is new to me.

uggggggggghh, then code flows!

a vision of zen and the art of going to the lavatory.

I use brute force - if it doesn't solve your problem then you are not using enough!

srod wrote:Tell Netmaestro you have an impossible problem to solve and that he couldn't possibly master it, sit back with a mug of coffee and a newspaper and await the code!

I have erm 'written' 150000 lines of code that way!

ROFLMAO

My philosophy is...

"Programs are little machines. The possibilities of such machine results from the sum and the quality of their properties/parts."

Regards

Wolf

My Philosophy is...Dig a short grave; runt size; wait for NetMaestro to catch up to srod and watch the mayhem, shove the dessicated corpse in and party!!!

Tom Cruise once said ''It doesn't matter what I believe, it only matters what I can proove'' - in A Few Good Men, if I'm wrong about that, then feel free to point and laugh.

If I don't understand the problem, or if I don't think it will work, then I simply won't even start coding it. Some people can just go onto a project without worrying too much about the details, as they plan to research as they go, but I find that unless I know that what I'm working on definitely does the job, I can't justify working on it.

I guess it might sound arrogant if I say that I already know that the code will work before coding it - but it's a factor of experience, not confidence. For example yesterday to help a buddy out I agreed to draw some sprites for him, Lode Runner to be exact, so nothing too difficult. I probably spent 2 hours on the sprites, then I made him a mini level editor in the space of 15 minutes, thing only has like 50 lines of code in it. Because I've made a lot of editors, I knew exactly the bare minimum of what was needed, and hammered the code in - thing compiled first time too. My point is not that I work fast, my point is that the little project sits perfectly in the groove I've worn with my techniques - a project that doesn't fit the groove is unlikely to succeed.

I guess this is the major factor in deciding what project to take on next. If you have to sit and think about if you can do it for any length of time, then you might be better off avoiding it - if you could do it, then the chances are you'd be doing it already!. Never start a project until you have a clear path, have tackled all the major components before, and can visualize the finished product clearly.
I've learned far more doing mini projects and messing with examples than any book I've read, and I've read at least 2.

vanbeck wrote:If you have to sit and think about if you can do it for any length of time, then you might be better off avoiding it - if you could do it, then the chances are you'd be doing it already!. Never start a project until you have a clear path, have tackled all the major components before, and can visualize the finished product clearly.

I disagree with this statement entirely!

I always try to improve my programming skills by taking on projects that i don't necessarily know if i'm going to be able to do. To learn new things you have to push yourself beyond your comfort zone and try something you find hard to do. I don't mean that a beginner should start trying to write a compiler but you should find something you don't know much about and incorporate it into a project to learn more.

It doesn't matter if you fail! You will learn more from your failures than you ever would if you never tried!

Here's an interesting blog post on the subject:

http://www.codinghorror.com/blog/archives/000300.html

My main approach to programming is:

► Write code as if others need to be able to read and understand it.
► Properly learn stuff that you found hard last year.
► Try starting and completing a project that you know nothing about.
► Learn a new programming language at least once a year.
► Do nothing malicious.

I agree with Kale 100%.

Only by pushing yourself will you master those hard to do things!

Hate to quote myself but...

I've learned far more doing mini projects and messing with examples than any book I've read, and I've read at least 2.

I agree completely, what I mean is that I make sure I know everything I need to before trying to implement it into a main project. Then I tend to recode, but the main thing is to get the untidy 'learning' code out of the way first.