Structured Programming

[na_th_an]

I do fine with fb, and really, whats wrong with using GOTO/GOSUB's, if the program works the that should be enough. Shouldn't it???

Axipher, you made a very good point here that perhaps the structured programming purists missed.

Your point is: "if the program works...". I think that's the important issue. You wrote it, you tested it, you modify it, and you're happy with it. Almost all the QB/FB programs that all of us here write are for our own use, and are not going to have to pass inspection by some programming standards committee. If some of us chose to use gotos or gosubs because we fell comfortable coding that way and have success doing so, then "to each his own."

If the programs we write were to be maintained by programmers other than ourselves, then yes, it would be a good convention to write these programs in a structured manner.
*****

The problem is, if we have to train and try to educate future programmers, we better teach them good practice.

I don't know how programming businesses are over there, but here, that you know how to do properly structured and indented programming is a must. Many businesses even have a "book of style" with directions on how to format your code. Because time is money, if some other employee has to keep with your project, it's better that he understands the sources in no time.

It's like when you are taking scripts. You get any pen on any kind of paper, and squibble fastly. Most of the time, you will understand it. I mean, it does the job. But what if you want the script to be read and understood, used and expanded by some other person? You have to use a proper paper, nice indentation and good callygraphy.

Structured programming is just that. It favourishes encapsulation, something that is a really important concept when you are going to work in a big project with more people. It favourishes readability. It also favourishes scalability. It's easier to debug and, most of all, easier to expand and to maintain.

I'm just talking of experience. I sometimes review my old programs and I have to spend some time figuring out where all those branches go and what do those unindented nested loops begin and end, which are inside which and stuff like that.

Plus, using GOSUBs instead of SUBs is horrid for scalability. Imagine that you code something and place all your subroutines behind labels and you use GOSUB to call them. Now leave that program for two years. After that time, your boss asks you to add a new capability that someone else coded. You cut and paste the code and... ARGH! Same variable names! everything goes haywire and you have to review the source line by line to replace the variable names. That takes time.

If you had used SUBs, you just stick the new SUB in your code and forget about it. You don't even have to read the new code. That's encapsulation.

That's why all my claims grow stronger and stronger. Meg has her own crusade as well. I think that in places like this we are "forming" future programmers. And no matter how we prefer to code, we should try to show them the "easiest way to success".

I do use GOTOs, but I strongly speak against newbies using them. Avoid GOTO like the plague until you know exactly what you are doing.