PureBasic Forums - English

srod wrote:Only kidding! My code's not as bad as I'm making out, [...]

I believe you. Anybody smart enough to keep reminding us "...I'm not a complete ass! " in his sign-off can't be a bad programmer.

srod wrote:[...] I still can't bring myself to grab a pen and paper and jot down a few algorthims or some psuedo-code etc. Just takes the fun out of it all!

Tsk! Tsk! Tsk! wrong approach. The words get in the way.
You see, there's pain and paper (to be avoided) as well as pen and paper... Carefully avoid confusing one with the other.
So, yes to pen and paper, NOT as in words and sentences (Goto pain:), but as in doodling.

I never start a coding task (not even menial ones) without first grabbing my pad and ballpoint pen, and doodling my way into my own ideas. The circles, arrows, lines and various marks help delimit the idea, and focus the effort. The rough stuff gets out of the way.

Sometimes, the sketch ends up nothing more than just a jumble of lines, arrows, concentric circles and question marks, but more often, it develops all by itself into a basic (as in rudimentary, not as in Pure!), but coherent, outline of the plan ("project" when it graduates into the grandiose).

That exercise, in itself, clarifies the process and really helps maintain the focus and purpose of the coding brain.

Thanks srod, for getting a great topic going. It's enlightening and a real pleasure reading what everybody has to say.

And just remember:
Forget flowcharts and fancy words.
Start Doodling.
it'll help keep your creative juices flowing and organized...

Exaclty what I do before making any project.

First, I design the GUI of the program on a paper, then I'll draw the flowchart also on a paper, after that I will write pseudo-code and finally do the PureBasic coding.

It depends on what you're programming. I'm a VB6 coder really, so I'm a PureNoob.. but I just love it! Compared to COBOL it's a dream!

For simple, 5-minute jobs (that end up taking hours! ) I'll just dive in, but it's technique... for instance...

Procedure MyLoop()

EndProcedure

Turns into...

Procedure MyLoop()
For MyLoopCounter = 0 to 9

Next MyLoopCounter
EndProcedure

Which in turn becomes...

Procedure MyLoop()
For MyLoopCounter = 0 to 9
x = MyLoopCounter * 10
Debug x
Next MyLoopCounter
EndProcedure

I kind of structure it out, and then "fill in the blanks"

For anything else it's usually a whiteboard+psuedocode or a good old-fashioned pen and paper.

I rarely, if ever use flowcharts or block diags. I basically use the above technique for everything and go from there. It soon becomes apparent if I've made a mistake, and it teaches to "think like a user". The worst thing a coder can do is try to explain something to a user with a block-diagram. You need to learn to say... "It does doesn't work because it's waiting *whatever*..."

It's how they think, and it's them that we are ultimately working for.

So there you go. The ethos of Vappy: "Wanna be a decent programmer? Think like a noob! Or better yet, a complete idiot"

I program in my head and then I move it from my head to japbe. Sometimes it leads to funny results

Mantra

New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
New features can wait for the next version!
... ahh bugger it, it's more fun to work on them now!

Also,

I practice "The art of distractable coding (tm)". Lots of little functions that can be finished quickly so that when things crop up (I'm not a programmer by trade so people don't leave me alone to do it) I can drop it at any time without losing my place by too much. "Atomic Coding" to attempt to use a buzz word

I have been learning to use the new EVENT LOOP in PB4.1... it has forced me to organize my code better...

As far as the interface I usually have a good idea for that before I begin in my head... Not that I don't rip that apart at will if need be...

I note my variables and attempt not to reuse variable names for cleaner code unless it fits... no crossover name problems on reuse!

I flowchart at times... it is how I was taught way back when... but not always...

When I find myself "thinking" in PB... then i know I am in the zone... and if I am OUT OF ZONE...

I post a thread for help with code...

How do you code?

Naked!

Flaming Amoeba wrote:

How do you code?

Naked!

and I thought I was the only one

Matt wrote:

Flaming Amoeba wrote:

How do you code?

Naked!

and I thought I was the only one

One less thing to do if you get distracted by internet porn!

I code by writing a complete and working mess while I get my head around the concepts/problems, and then I rewrite it 2-4 times, each time it gets cleaner and more efficient as my understanding becomes clearer.

The downside is that it takes me a while to produce something beautiful. Which for business they don't care, so they get my first stab and then work from there.

> I rewrite it 2-4 times, each time it gets cleaner and more efficient

That is so true. If I've written an app (a small one I mean) and then I delete
it (by mistake or on purpose) and decide to rewrite it, the new version is so
much cleaner and better. It always amazes me, but I guess it's because it's
been done once so you know what to do right and what to avoid.

But it's not just coding either. When I was a little boy (way back in the day!),
and I'd build a fort or something with Lego, then if it got destroyed (dropped)
and I rebuilt it, the rebuilt version was always much better too.

PB wrote:> I rewrite it 2-4 times, each time it gets cleaner and more efficient

That is so true. If I've written an app (a small one I mean) and then I delete
it (by mistake or on purpose) and decide to rewrite it, the new version is so
much cleaner and better. It always amazes me, but I guess it's because it's
been done once so you know what to do right and what to avoid.

But it's not just coding either. When I was a little boy (way back in the day!),
and I'd build a fort or something with Lego, then if it got destroyed (dropped)
and I rebuilt it, the rebuilt version was always much better too.

I thought that was just me...

I write test first, but using story tests rather than the usual unit tests.

First I write a story. Somebody does this, then that, they get these results. Then the do the other.

Write up the story as an executable test, and write the code that will cause that test to pass.

http://industrialxp.org/storyTdd.html

I do this now because I'm doing a lot of non-GUI work. When you're writing something with a GUI I do that a feature at a time, running the code constantly to make sure it's still working.

With stuff that is non-interactive I use the story test approach so that I can keep that constant feedback about the state of my code.