PureBasic Forums - English

Hi All,

Its a simple question, and there are obviously no right or wrong answers, but it would help me.

As i learn to use PB i find that i have an idea, i try some things out, and then eventually get it to work one way or another. This approach leads to a final program which is very messy and cluttered. Sometimes i am able to tidy it up after it's working. I have found that writing things down as i think of them helps, even doing simple drawings.

What i am asking is how YOU code. Is there a simpler way of creating tidy more efficient code. Should i create flowcharts? Is it more useful to create pseudo code on paper?

Thanks

Chris

Never used flowchart stuff.
Forget all of these.

Remember:
1) Predeclare variables
2) Use good variable names
3) Do not use a simple var like i as for next loop
4) Make your code modular, write include files and prepare a set of related functions in a single module only.
5) Free (memory?) what is claimed.
6) Study code from others
7) Don't be to lazy.

Rule #1 Don't be lazy!

Personally i just get stuck in and code. I have no real design plan but then the apps i code really aren't that big. One thing i always do is, I always and i mean always make my code tidy and very very readable! I think this is under stated to some people, the need for good clean very readable code will come apparent to you in 6 months time when you have to update your program Also if there is a particulaly fancy bit or a super optimised algo in ASM comment it like mad! When you write your comments imagine that you are writing them for another coder who has to understand what you are doing, that way they will make sense to you when you read them again. When i name variables or constants, etc. I also use real names not just: which means nothing to me! This is more readable: and its immediately clear what this variable represtents.
I also name all variables using 'camel hump notation' like this: not like this: again making it instantly more readable. I never ever use Hungarian Notation like this: which makes everything look a mess. I use the * character: again readable and clear.
For Structure names and Constant names i also use all uppercase letters like this: Which seems to be standard C/++ style and kinda looks right with the rest of my source.

Also as Edwin has said break your source into many files and include them into a main file, this way you can break up stuff like var/constant declares, the datasection, even the WindowsCallback, making it a little easier to navigate your code using the tabs in the IDE rather than searching through a huge source. See the IDE source code for an example of this.

Well thats how i do it and it remains readable to me even after a long time coming back to a source. Sort yourself out a nice way of working and more importantly stick to it! Then all becomes more tidy

Yes, lazyness is the coder's enemy

Always a full variable name. Even if it is a lot of typing, but if the name allready
states the use of the variable, you don't need an extra comment to explain it.
Same for procedures.

One thing I would also suggest is to always use "$" for strings. This makes
it more clear what is what, instead of using the ".s" way, where a string
looks exactly like a long value.

What I do for bigger projects is to always plan ahead all features that
the program should have, and how they should be connected.
(I mostly do this in boring history lessons at school )
Usually i can keep all that in my head, but sometimes i also write it down.

Note, that I don't plan how to actually code stuff, but only what it should
do.

Then I usually start off with the base layout between those features,
and the commonly used functions. The good point about that is, that it
reduces the need to rewrite code later, and the code is more efficient,
because you reuse functions a lot.
This also forces me to clearly define what I want to do first, and then do
it, which is imho better than inventing things *on-the-fly* while coding.

However, this usually means, that it takes a long time of coding lots of
functions until i first execute a code. You have to to things right there,
or you have a hell lot of bugs when you first run the code. So this might
not be the best aproach for some people, especially when you are new
to the language.

When I want to use something new in my code, that I never did before,
I usually try that out in a small project first, to get familliar with it.
In those little projects, i do it the other way around. I start with a few
lines of code that work, and then mess around with it a lot.

The result is not well designed code, and sometimes unusable, but i have
learned a lot, and can then use the stuff in my bigger projects.

Um, lot of talk... need to go now...

Timo

Another pearl of wisdom i have found to help me is that the deffinition of a function (or procedure) should be something that does only 1 thing AND does it well! Sometimes easier to find bugs with this approach.

I'm allways separating my variablenames with ' _ '.

As this, for example:
or For me, it's better to write with ' _ ' as with capitalization during a name.

hey sunny, that's the same way i do it

- i also have a habit of using certain vars for specific purposes:

n nn nnn for quick and dirty loops
k for small (single) bytes from keyboards, files, memory blocks

- i use underscores (don't like mixes of lower / uppercase, lowercase is for my vars, uppercase is for my keywords)

- i use postfixes for variables related to eachother...

for pointers i either use *varname or varname_p
for the length of something it's whatever_l
when i keep a counter for a number of lines or elements it's counter_n
when working my way through something i use something_p

- it varnames get too complex or long, i sometimes use 'intermediates' especially when dealing with long / complex names (it's very good if you can read them, it's not so good if a line gets so long you can't figure out anymore what the hell was going on ) or when dealing with structs

- don't make an expression too long or complex, split it up if necessary

- don't use variables for other purposes than you declared them for (oh, i have this n that i don't need in this part of the code, let's use it to store the user access codes), that saves me 4 bytes

- try to be *extremely* consistent in your procedure naming scheme, use parameters that make sense

don't do procedure.l power(a,b)
do procedure.l power(base.l, power.l)

most code i just hack away, sometimes i settle down and think something over in pseudocode (the more complex stuff), i never use flows since i left school... well, i did for operational stuf inside a company (what people should do when this or that happens) but not for code

spongehammer wrote:Hi All,

Its a simple question, and there are obviously no right or wrong answers, but it would help me.

As i learn to use PB i find that i have an idea, i try some things out, and then eventually get it to work one way or another. This approach leads to a final program which is very messy and cluttered. Sometimes i am able to tidy it up after it's working. I have found that writing things down as i think of them helps, even doing simple drawings.

What i am asking is how YOU code. Is there a simpler way of creating tidy more efficient code. Should i create flowcharts? Is it more useful to create pseudo code on paper?

Thanks

Chris

- np

ps - all code is pseudo code until properly digested by the compiler

WoW

what an excellent response.
Some interesting points there too. I just have to put them into practice now
My main problem has always been with variables. I must admit i tend to use the first thing that comes into my head. :roll:

BTW Edwin: Why Predeclare variables ?

Thanks to all.

Forget about "coding" and think "data structures". Everything falls into place once you know what data structures are required and what you need to do with them. This is best done with high tech multi-function code design utilities, ie, pencil with integrated erazer and lots of scrap paper. Main benefit is when you start coding you at least have a good overview and a clear idea of where your going, thus avoiding the well know RD problem solving technique known as the "random walk". "RD?" I hear you ask... that's the opposite of AI... Real Dumb.

Once coding put ***ALL*** your variables into structures and include plenty of error checks and debug messages (centralise if poss with custom dbg proc, so easy to disable later). Because PB lacks an option for declaring all variables and especially a decent debugger, hours, days or even weeks can be lost tracing STUPID bugs such as typo's.

PS: I bet you have your fingers on the keyboard at this moment already "designing" your program eh? Tut, tut. As I get older the more I subscribe to the now ancient rule-of-thumb: 90% designing, 10% coding

Thanks dmoc

PS: I bet you have your fingers on the keyboard at this moment already "designing" your program eh? Tut, tut. As I get older the more I subscribe to the now ancient rule-of-thumb: 90% designing, 10% coding

Some famous American President once said something like
'If i had 5 days to cut down a tree i would spend 4 of them sharpening the axe'

i think

Chris

I'm betting this wasn't Bush right? Else it would be: "Tree? Tree? No, I said my name is Bush! Eh, wait... I think something's coming into ma' 'ead... yeah, we can confirm, finally, we did find some axes in and around Iraq, real evil one's! Damn, there goes those voices in ma' 'ead again... must play golf... must play golf...

PS: f**k me! When did I become a "Wizard"? You can't just go promoting me without discussing a salary rise 8O Guess now I have to change my name to Harry or 'arry... or does JKR have copyright on that as well?

ROTFLMAO

Thank you for this one

In VB you have option explicit.
It forces you to declare a variable.
This should not be an option but forced.

Also weird things like defint a-z is hopeless.
PB lackes forcing var declarations (afaik).
I real must have since every aspect must be control by the programmer.
So you really know if the variable is used or not.
And not able to reuse a var for different types.

Programming, like i said, everything created should be destroyed in the oposite order.
Try to get 100% control over your code, only then you become certain that it's correct.
If a procedure works as expected it does not mean it's correct, that's my point.

Programmers sometimes need to be forced to a specific way of coding.
DefInt or a deflong does not fall in that category.

Hello spongehammer,

IMHO to answer well your question, first you may have a look at Code Archive (http://www.purearea.net/pb/CodeArchiv/CodeArchiv.html) where you will find hundreds of code advanced samples.

Most of the time, I noticed that PB users are pretty good coders doing a neat coding.

My own way to code, either using PB or any other language is to use easy understadable variables and constants names, and then using indentation for instructions editing.

Indentation means that i.e. a code between an IF / ENDIF Statement (may be For / NEXT or REPEAT / UNTIL etc) has a specific tab so that if you read it vertically you will find the corresponding end part of code at the same comuùn than start part of code.

Then be careful on one point I learnt 30 years ago ... Anything which seems to be repetitive should correspond to a procedure.

This makes the executable sometimes slower but lets you thik to higher level issues.

Learn about recursive programming, procedures benefits, and probalby later, if you feel really a newby to Win API stuf.

This is a fact that Fred PureBasic is certainly the best possible language for designing software.

This is also a fact that most PB coders think Windows. Just forget it first and go back on it later. Windows is the most used operating system and environment but has nothing to do with your coder's expectations ...

When using PB as a designing environment, try first to imagine what you want to do, and then how it may apply on the deisgn evironment you have got.

Have you got PureBasic, then be sure you can do anything you thought.

I do so.

Just it may takes some minutes, hours, or days to do. But PureBasuc alows to do to anything you thought first.

Are you experienced more or less in using computers, softwares, hardware, networks, any user experience / requirement has its reply coding with PureBasic.

This is the reason why I recommand first to take some hours downloading and reading Code archive samples.

On my own, wheb I post sample code, I try to be at the best possible level for teaching or answering any posted issue. I do not have always the right answer.

How I do code ...

Let's give an example :

Step 1

I wish to display square root of two on the console

Verbs are display and wish

Forget wish ... just think 'Do'

Step 2

What is Square_Of_Anything using PB ?

Have a look, even if it takes some hours to parse pages, at the PB help file.

A square root is sqr(n)

sqr(n) uses a function : Sqr and an argument n

Then you have to solve about the function and the argument. PB does assume the function Sqr which is not the case of any function / procedure you will see in Code Archive. Some functions are not PB functions but 'externals'.

Anyway Sqr is a PB function, then it just remind the argument to understand.

First understand that Fred (PB founder) made things working so that you may send any argument you wish without insulting you when the argument is not of the right kind.

Then you may try either Sqr(2) or Sqr(2.0) which reprensent respectivliy an integer and a float values.

Why try to be understanble in variables names ?
Test it and undesrstand then ...

Before to have a meaning any computer objects, being a bit, a byte, a word a structure, a proceure or a softawre application, has it formats.

I can imagine, let(s hope I am not wrong, that you are human with 2 eyes, two arms, two legs, a noze and some other stuff, would you look without having defined what's your eyes are and feel ?

Then let's your mind imagine what you can do ...
Here you defined eyes as a something that do not need anything.

Then ...
Here you have just defined that you are drawing a point somewhere ... but always at the same place.

Let's go further :
Here you have a point plotted close to the mouse position (just be careful to see this point).

May you want to look a better rendering about what eyes should be ?

Use this :
Then you have a code there which corresponds to a first 'higher level' but not exactly well coded :

Here you define better what eyes are undependantly of what your vision is large ...
Just one more trick to make the coding better :

Change where you are looking or not ?

Never execute instructions that are unnecessary ...

This is just for not consuming the CPU for nothing.
Does this help for a better understanding ?