Should Declare use be avoided as much as possible?

[Nituvious]

Hi all, I have been writing a small program that uses several include files to keep code managed(yay, source management!). Recently after attempting to entirely deprecate my handy dandy "dostuff()" function I can no longer call important functions that rely on several other functions that come from the several include files.

I feel that my only option is to either cram everything together and make readability and management difficult or to use the Declare keyword.

However, I've been told that it should be avoided(here). Why is this? What makes declare bad? In languages like C I've seen functions declared much like I need here, but I've never really understood why this is.
I can understand why the use of GOTO would be considered a bad practice, but why would declaration of functions be bad?

[MachineCode]

There's nothing wrong with "Declare". Ignore the recommendation not to use it. Sometimes, it's impossible to use two procedures without it. (One of my apps has this situation).

[Shield]

Not "Declare" is to be considered bad, but procedures that require each other is, which then again requires one of them to be declared.
So try not to write code like this:

Code: Select all

Procedure.i AAA()
    BBB()
EndProcedure

Procedure.i BBB()
    AAA()
EndProcedure

Try to create a structure in your code that doesn't depend on those things.
If you do that correctly, you don't even need declare.


In C, functions need to be declared in header files because there is no other way to access them since they
are compiled to object files. Without a declaration, a function can't be called from the outside.

[luis]

There is nothing wrong with the use of declares in PB.

When you are writing a lot of procedures and you want to put them in your source following a certain order because it makes sense (for example group them in the source by functionality, or separate the internals from the public ones, or whatever) declares help you to make this possible.
Do you prefer to continually juggle the procedures order to make them work and break any form of organization you built or to do what you like to do and let declares take care of the rest ?

Moreover with a single pass compiler sometime you don't have a choice, and you can generate declare automatically with a simple tool you can write by yourself, so I don't see why struggle when you don't have to.

And GOTOs should be avoided when possible, but in a language like PB (or C) without exceptions handling they can be very useful and make code clearer and more easily maintainable, especially forward GOTOs. Backward GOTO are generally very hard to justify.

[Nituvious]

Thanks for the input!
I will use Declare as little as I can, I just thought there was some unspoken evil that would be summoned if I used declare.

[offtopic] luis you're signature is the song of my life

[Zach]

I love Declare. I hadn't used it before, but when I started using EnableExplicit to rewrite my current project, I figured if I have to define my variables ahead of time, why not procedures as well?

Plus it gives you a good references at the top of the Procedure stack, if you've commented what each procedure is responsible for with its declare.

And like has been said, sometimes you need it. It's not even about cases where two Proc's reference each other.. Any time you have to call a Procedure inside another Procedure, you will need declare, or you will be forever reshuffling your code, to make sure the order of reference matches.

[Tenaja]

Not "Declare" is to be considered bad, but procedures that require each other is, which then again requires one of them to be declared.
So try not to write code like this:

Code: Select all

Procedure.i AAA()
    BBB()
EndProcedure

Procedure.i BBB()
    AAA()
EndProcedure

Try to create a structure in your code that doesn't depend on those things.
If you do that correctly, you don't even need declare.


In C, functions need to be declared in header files because there is no other way to access them since they
are compiled to object files. Without a declaration, a function can't be called from the outside.

Actually, there is nothing wrong with recursion--as long as it is deliberate. Your example code is perfectly acceptable coding practice, and in fact, the perfect example of how to solve some issues that are best solved with recursion. There is a reason we have names like "recursive descent," and that is because we intend for recursion to solve the problem.

[Shield]

No, that's actually a very bad example for recursion.
Imagine there is more code in there and say those functions do trivial things like modifying Gadget layouts.

You'll have a really hard time to find those bugs later on. It's just not a good programming style.
Recursion should be limited to one procedure calling itself and not calling itself by calling another function that does
divert the call back to the old function. It's just a mess.

Of course there is nothing wrong with recursion in general.

[Tenaja]

No, that's actually a very bad example for recursion.

Then apparently every recursive descent compiler is bad, in your estimation...because they are nearly ALL structured that way. Obviously, they have additional code, but that's the most common way to parse a= b*(a+b) with precedence. The multiplication is the highest precedence so it is on the bottom of the call chain, at the BBB proc, but the parens force a call to AAA, which is just another expression of unknown contents.

[Blood]

I've been told that it should be avoided(here). Why is this? What makes declare bad? In languages like C I've seen functions declared much like I need here, but I've never really understood why this is.
I can understand why the use of GOTO would be considered a bad practice, but why would declaration of functions be bad?

I said try to avoid it. As others have said sometimes it's unavoidable with procedural languages which IMHO is a suggestion of the limitations of that paradigm. OOP solved this years ago.

[nigel]

I always prefer to use subroutines wherever possible instead of functions/procedures. Subroutines are intuitively easier to read and comprehend.

There is nothing wrong with the Goto statement either. When used judiciously, its deployment can improve code legibility and readability, leading to easier maintenance.

Do not worry about receiving abuse from "code snobs" that wish to look down upon the BASIC programming paradigm. Trust your own judgement in these matters and ignore the screaming and gnashing of teeth.

[Tenaja]

There is nothing wrong with the Goto statement either. When used judiciously, its deployment can improve code legibility and readability, leading to easier maintenance.

Far from being a code snob, I cut my teeth on basic and assembler. I know several of the bracket-based languages, but I prefer basic. However, reading that just makes me think you have never had to read someone else's code... "structured" code flow is easier to read for 99% of us reading code written by another person.

And yes, I use Goto a lot, but only when code size and/or speed matters greatly.

[Shield]

@Tenaja:
The problem is that such procedures can lead to confusing code.
For a recursive descent parser (and probably many other examples) it's fine,
because in such a scenario, if AAA and BBB were part of an RDP, it wouldn't make too much sense
to call BBB outside of a context of AAA.

But just because there are useful examples (which is often the case), that doesn't mean
that a specific way of doing one thing is good for another thing, too.

Same goes with the goto statement. It isn't bad at all to use it...but use it wisely.
Frequently using goto statements can lead to very confusing spaghetti code, especially in PB
where you can jump from any position to any other location inside the source, even "cross-procedure".
Other languages restrict the usage of goto to the current scope which makes the use of it much safer.

[Tenaja]

@Tenaja:
The problem is that such procedures can lead to confusing code.

Sure, but just because recursion is "most frequently" used with a function calling itself does not make pairs of functions calling each other a bad example of recursion.

Same goes with the goto statement. It isn't bad at all to use it...but use it wisely.
Frequently using goto statements can lead to very confusing spaghetti code, especially in PB
where you can jump from any position to any other location inside the source, even "cross-procedure".
Other languages restrict the usage of goto to the current scope which makes the use of it much safer.

I with you here...it took me a while to get transitioned to "structured" coding, but it is far easier to read and maintain!

There is always a balance between power (i.e. C) and preventing stupid mistakes (i.e. Pascal). I like the balance that PB has, but think it should prevent a Goto with the target being in a different procedure. Afterall, extreme care would have to be taken to avoid stack overflows... something that "basic" coders are not famous for.

[Shield]

True. Probably used the wrong words there.