I thought it might be helpful to beginners at least to have a blog that covered good programming practices. Some might simply be helpful habits that save a bit of time. Others might be approaches that potentially make the code easier to maintain. Inevitably one person's practice could be another person's bad habit. It all depends on what the code is for and whether it has any chance of a long life.
Many users of Picaxes will not have had any software training. Electronics has been after all mainly a hardware discipline until now. However, the two disciplines of hardware and software engineering are merging rapidly, and each can learn from the other.
So I invite forum members to add short tips that they feel might be helpful to those without a background in software, with the objectives of saving time in design, reducing debugging and maintenance effort, prolonging the life of code, etc.
I thought I would start with a simple statement about the use of the GOTO, a bit of a hobby-horse of mine, but based on experience. I have programmed in most language types over the years and currently have around 3000 lines of Picaxe basic running 24 x 7 in my house operating things that I don't want to go wrong over many years.
GOTOs are unnecessary and lead to code that is hard to maintain
-----------------------------------------------------------------------
Why? Well it isn't the goto itself that is the problem, it is the label to which the goto points. It is impossible in any program of length to be perfectly clear about the paths through the code unless they are explicitly coded. If you look at a piece of code that has labels in it, from where does control come from when the program runs? Generally, it is very hard to tell. You only have to look at some of the beginners spaghetti that is on the forum to know this.
There is lots of academic background about program proving that explains why, but in practice, all you need to do is use the explicit control structures that are available instead. If you don't have labels then you won't use them. Furthermore, using proper structures will help you think through the program flow much more rigorously. The result will be code that is easier to understand as you write it, and much easier to modify a year or two later.
So, where you see
main:
(code)
goto main
simply use
Do
(code)
loop
You can nest these loops quite deeply.
In fact so far as I can tell there is only one case in Picaxe Basic where a goto is necessary, and that is when a timeout is used in serial communications. If you have to have gotos, such as in this case, the safe way to do it is to make sure gotos always point downwards and cannot create loops. Loops should have proper control structures (e.g. loop while or loop until etc.). The EXIT command is a very useful way of exiting loops without using a goto.
Variable labelling
-------------------
While I'm on a roll I will add a second tip. Some may think this unnecessarily bureaucratic, but it really does make a difference!
I always name variables and constants with a prefix that explains what the variable type is. This way, it is much harder to mistakenly assign e.g. a Word to a Bit and not understand the subsequent program behaviour. I use W_, B_, C_, F_ as prefixes for Words, Bytes, Compiler Constants and Flags (bits). If there are different types of constants, e.g. in my finite-state-machine code, I use St_ and Ev_ for states and events. You can invent your own terminology. The effect is to make it clear when you read the code just what each name represents and is capable of. You might be surprised just how many problems this prevents.
That is my two-pennyworth for the moment. I don't expect everyone to agree, but that isn't the point. Perhaps you have your own tips that you will contribute.
Many users of Picaxes will not have had any software training. Electronics has been after all mainly a hardware discipline until now. However, the two disciplines of hardware and software engineering are merging rapidly, and each can learn from the other.
So I invite forum members to add short tips that they feel might be helpful to those without a background in software, with the objectives of saving time in design, reducing debugging and maintenance effort, prolonging the life of code, etc.
I thought I would start with a simple statement about the use of the GOTO, a bit of a hobby-horse of mine, but based on experience. I have programmed in most language types over the years and currently have around 3000 lines of Picaxe basic running 24 x 7 in my house operating things that I don't want to go wrong over many years.
GOTOs are unnecessary and lead to code that is hard to maintain
-----------------------------------------------------------------------
Why? Well it isn't the goto itself that is the problem, it is the label to which the goto points. It is impossible in any program of length to be perfectly clear about the paths through the code unless they are explicitly coded. If you look at a piece of code that has labels in it, from where does control come from when the program runs? Generally, it is very hard to tell. You only have to look at some of the beginners spaghetti that is on the forum to know this.
There is lots of academic background about program proving that explains why, but in practice, all you need to do is use the explicit control structures that are available instead. If you don't have labels then you won't use them. Furthermore, using proper structures will help you think through the program flow much more rigorously. The result will be code that is easier to understand as you write it, and much easier to modify a year or two later.
So, where you see
main:
(code)
goto main
simply use
Do
(code)
loop
You can nest these loops quite deeply.
In fact so far as I can tell there is only one case in Picaxe Basic where a goto is necessary, and that is when a timeout is used in serial communications. If you have to have gotos, such as in this case, the safe way to do it is to make sure gotos always point downwards and cannot create loops. Loops should have proper control structures (e.g. loop while or loop until etc.). The EXIT command is a very useful way of exiting loops without using a goto.
Variable labelling
-------------------
While I'm on a roll I will add a second tip. Some may think this unnecessarily bureaucratic, but it really does make a difference!
I always name variables and constants with a prefix that explains what the variable type is. This way, it is much harder to mistakenly assign e.g. a Word to a Bit and not understand the subsequent program behaviour. I use W_, B_, C_, F_ as prefixes for Words, Bytes, Compiler Constants and Flags (bits). If there are different types of constants, e.g. in my finite-state-machine code, I use St_ and Ev_ for states and events. You can invent your own terminology. The effect is to make it clear when you read the code just what each name represents and is capable of. You might be surprised just how many problems this prevents.
That is my two-pennyworth for the moment. I don't expect everyone to agree, but that isn't the point. Perhaps you have your own tips that you will contribute.