M
Michael Griffin
Bob Peterson wrote:
<clip>
> Mr. Peterson's main issue is badly written code. I really do not care much
> what method is used as long as it is consistent, works well, and has few
> gotchas. The worst programs I have had to fix generally seem to have an
> overabundance of latches in them, and inevitably there are a few somewhere
> in the code that don't get reset along the way, so things don't work quite
> right.
<clip>
I think I see your point. I believe however that bad programs tend to have an overabundance of a lot of things in them. The way the worst programs tend to come into being is when someone tries to fix a bad program by adding more stuff onto it instead of taking the bad parts out. If they can't add more latches though, they'll just add something else instead.
I once had to add a new feature to a machine. After several days I gave up trying to understand the existing program, and wrote a whole new one with the new feature in a few hours (it was a simple machine). My new program was one
eighth (1/8) the size of the original, but did more.
I regret having discarded the old program, as it made such a good example of a bad program. One feature of it which I recall rather well was a couple of pages of statement list full of jumps and obscure instructions which was basically equivalent to a single rung of ladder logic with a few contacts controlling an on-delay timer. The original program was written by an electrical engineer who worked as a programmer for a large machine builder, so it's not as if he was inexperienced.
> And I do believe in keeping the code as simple as possible. Occassionally,
> you have to program an algorithm that is not particularly simple. These
> are fairly rare in general purpose automation projects. Most of it is
> pretty simple stuff, just a lot of it. Break it down into managable
> chuncks and program that chunk. The worst part tends to be interlocks
> between the chuncks.
<clip>
It's really rather easy to write a large complex program, people do it all the time. Writing a simple program is what many people find difficult to do. This is what takes thought and experience.
I think that what you have described in the above is a much better guide on how to write a good program than a detailed list of "things to avoid" would be. Identifying various general things as bad practices doesn't mean you will end up with a good program. The things you are proscribing are the symptoms, not the causes of the problem. A good method used for the wrong thing still results in a bad program.
************************
Michael Griffin
London, Ont. Canada
************************
<clip>
> Mr. Peterson's main issue is badly written code. I really do not care much
> what method is used as long as it is consistent, works well, and has few
> gotchas. The worst programs I have had to fix generally seem to have an
> overabundance of latches in them, and inevitably there are a few somewhere
> in the code that don't get reset along the way, so things don't work quite
> right.
<clip>
I think I see your point. I believe however that bad programs tend to have an overabundance of a lot of things in them. The way the worst programs tend to come into being is when someone tries to fix a bad program by adding more stuff onto it instead of taking the bad parts out. If they can't add more latches though, they'll just add something else instead.
I once had to add a new feature to a machine. After several days I gave up trying to understand the existing program, and wrote a whole new one with the new feature in a few hours (it was a simple machine). My new program was one
eighth (1/8) the size of the original, but did more.
I regret having discarded the old program, as it made such a good example of a bad program. One feature of it which I recall rather well was a couple of pages of statement list full of jumps and obscure instructions which was basically equivalent to a single rung of ladder logic with a few contacts controlling an on-delay timer. The original program was written by an electrical engineer who worked as a programmer for a large machine builder, so it's not as if he was inexperienced.
> And I do believe in keeping the code as simple as possible. Occassionally,
> you have to program an algorithm that is not particularly simple. These
> are fairly rare in general purpose automation projects. Most of it is
> pretty simple stuff, just a lot of it. Break it down into managable
> chuncks and program that chunk. The worst part tends to be interlocks
> between the chuncks.
<clip>
It's really rather easy to write a large complex program, people do it all the time. Writing a simple program is what many people find difficult to do. This is what takes thought and experience.
I think that what you have described in the above is a much better guide on how to write a good program than a detailed list of "things to avoid" would be. Identifying various general things as bad practices doesn't mean you will end up with a good program. The things you are proscribing are the symptoms, not the causes of the problem. A good method used for the wrong thing still results in a bad program.
************************
Michael Griffin
London, Ont. Canada
************************