Ok, Heater, I don't mean to say we need to keep all the list of previous versions. But if, say we make something that works, but then suddenly think of a better way to do it, then change the code and end up with a mess, -then it feels good to be able to get back the working version again.
1) Read the book "Clean Code" and or watch a bunch of videos about clean code on You Tube.
2) Don't listen to anyone who tells you there is one methodology or technique that will solve all you software creation problems.
I use the "What Happens Next" approach, Along with "If......then, Else........Only 2 choices at each decision, Go straight or turn left.
Interesting. At heart that is all you can ask computer programs to do, sequence, selection and iteration.
That is: Do A then B. Do A or B. Do A, B times.
Thought I would offer my own strategies here. I think for the most part I tend to flowchart my code if it is complex. But either way I generally try to establish declarations first, such as I/O pin assignments, constants and variables. Then I create a simple program loop and build the subroutines (BASIC Stamp) or methods (Propeller) one at a time, testing as I go, debugging as necessary before moving on to the next routine.
...One thing I often come across is what I want to do, but I am unable of how to actually program that function. The Propeller Manual serves as a great tool, but often I have no idea what syntax to even look for. Is there a method that you have for overcoming this?...
That problem is sort of like knowing a spoken language like English and needing to say something in another language like French. How do you say that?
Or how do you code that?
This can be frustrating, but I like it because it is a challenge and I learn the most while hunting for methods or commands with which to program the new function.
...then look through that and see if anything looks promising.
If I can't find a solution that way, then I will look at other programs which do similar things and see how they did it. Some things are not obvious by looking at the programming language. For example, a time delay might require counting up to a large number in the millions - just keep adding 1 to a variable until you get to a certain number. Something like that can be more easily seen in another program. (How do you do that?)
And consulting several different books on the same language is a big help sometimes. One book may explain something better than the others.
If I've learned anything in my 40+ years of programming, it's to do it a little bit at a time and to test each part as I go.
If you take anything out of this thread, take that.
Most of the code I write for EFX-TEK customers is very simple (BS1 stuff) -- typically when they call for help because they've violated Phil's suggestion. They rush head-long into writing an entire program, and then become very confused with the large number of errors.
For me, I want to know where I'm going before I start. Like GPS, without a destination, it cannot give you instructions. If you know the outcome, you can start. Your course may change as you learn new things, but the destination remains.
Once I know what a program is supposed to do, I break it down in the components that are needed. For a Propeller program, I may need to write an object if I don't have what I need. Then I create a skeleton program on which code will be added later.
And back to Phil's point: that code will be added a little at a time, and tested at every step.
I fully agree to how important it is to break the task into modules that are small, have clearly defined interfaces (input&output), and are easily testable. But for me the main challenge is to make a bridge from the conceptual idea in my head, and over to what is the first stage of designing the program. What I have found is that it helps drawing up a map of all variables (give them full names), and then start drawing arrows, loops, make notes, etc - i.e. defining the processess required to act on the variables. Then comes the time to start outlining subroutines, design them as selfcontained modules, code, and test them. When they are tested individually and work fine, then's the time to start integrating several modules and test, and onwards to it is all complete.
It is good to be ambitious, but try to mark out as much as possible in your ambitious project as optional functions/features, meaning you only reserve 'space' for them to be done later, but avoid having to solve everything in one go. This will increase you success (=completion) rate dramatically.
What I have found is that it helps drawing up a map of all variables (give them full names), and then start drawing arrows, loops, make notes, etc - i.e. defining the processess required to act on the variables.
I like your thinking when it comes to variable names. Variable names like "x" or "a1" don't give any meaning to what they're being used for. I even try to avoid shortened words or abbreviations for variable names. I also try to apply the same concept to pin declarations and constants. Commenting on these declarations always helps too, for example, something I borrowed from JonnyMac from some older BASIC Stamp code (2004) was commenting pin declarations for an IC in a more readable but succinct manner. For example one of the pin declarations sections for one of my programs looks like:
ADC_CS = 7 ' To ADC0831.1
ADC_CLK = 8 ' To ADC0831.7
ADC_DATA = 9 ' To ADC0831.6 (via 4.7K resistor)
DS1620_RST = 13 ' To DS1620.3
DS1620_CLK = 14 ' To DS1620.2
DS1620_DAT = 15 ' To DS1620.1
Usually the only time I deviate from this is if I am modifying someone else's code.
Comments
Yes indeed.I get very nervous about breaking something that works:)
After a while you realize a source code repo does exactly what you want to protect yourself from yourself:)
Along with "If......then, Else........
Only 2 choices at each decision, Go straight or turn left.
Writing small portions and trying until desired results are obtained, then moving to next problem.
Amazon has a good deal on the kindle version:
http://www.amazon.com/Robert-Martin-Clean-Collection-Series-ebook/dp/B00666M59G/ref=sr_1_2?ie=UTF8&qid=1382210521&sr=8-2&keywords=clean+code
Just bought it and reading it now.
C.W.
Interesting. At heart that is all you can ask computer programs to do, sequence, selection and iteration.
That is: Do A then B. Do A or B. Do A, B times.
Must be easy then:)
Anyone else read these books. $31.34 might be a good deal but it's still more than I spend on most books.
Makes programming even easier:)
That problem is sort of like knowing a spoken language like English and needing to say something in another language like French. How do you say that?
Or how do you code that?
This can be frustrating, but I like it because it is a challenge and I learn the most while hunting for methods or commands with which to program the new function.
I try to find a programming language quick reference like this one for C...
http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/so2/pub/documentos/c-refcard-a4.pdf
...then look through that and see if anything looks promising.
If I can't find a solution that way, then I will look at other programs which do similar things and see how they did it. Some things are not obvious by looking at the programming language. For example, a time delay might require counting up to a large number in the millions - just keep adding 1 to a variable until you get to a certain number. Something like that can be more easily seen in another program. (How do you do that?)
And consulting several different books on the same language is a big help sometimes. One book may explain something better than the others.
If you take anything out of this thread, take that.
Most of the code I write for EFX-TEK customers is very simple (BS1 stuff) -- typically when they call for help because they've violated Phil's suggestion. They rush head-long into writing an entire program, and then become very confused with the large number of errors.
For me, I want to know where I'm going before I start. Like GPS, without a destination, it cannot give you instructions. If you know the outcome, you can start. Your course may change as you learn new things, but the destination remains.
Once I know what a program is supposed to do, I break it down in the components that are needed. For a Propeller program, I may need to write an object if I don't have what I need. Then I create a skeleton program on which code will be added later.
And back to Phil's point: that code will be added a little at a time, and tested at every step.
It is good to be ambitious, but try to mark out as much as possible in your ambitious project as optional functions/features, meaning you only reserve 'space' for them to be done later, but avoid having to solve everything in one go. This will increase you success (=completion) rate dramatically.
I like your thinking when it comes to variable names. Variable names like "x" or "a1" don't give any meaning to what they're being used for. I even try to avoid shortened words or abbreviations for variable names. I also try to apply the same concept to pin declarations and constants. Commenting on these declarations always helps too, for example, something I borrowed from JonnyMac from some older BASIC Stamp code (2004) was commenting pin declarations for an IC in a more readable but succinct manner. For example one of the pin declarations sections for one of my programs looks like:
Usually the only time I deviate from this is if I am modifying someone else's code.