Sorry your browser is not supported!

if a=1 and b=1 or c=1 and d=1
if a=1 or b=1 and c=1 or d=1
if a=1 or b=1 and c=1 and d=1 or e=1

how do i know exactly how the boolean operators are operating?
that is, is the second line
"if (a=1 or b=1) and (c=1 or d=1)"
or is it "if ((a=1 or b=1) and c=1) or d=1"
i hope you understand my question
would be nice if i could use these ('s in the source code
what is a "(" called anyway?



the other question, not so important:
people say goto's are bad. the help file says its only their for compatibility with older basic languages. do you use goto's? there are three in my program.

two fo the goto's are used in my window, if the mouse is on the button and clicks then goto quit or goto save or whatever
another goto is used in the input section: if jumping=1 then goto noinput
and noinput is after the WASD commands, but before the mosue commands so u can still look while you jump(u can jump forward and stuff dont worry)

first: You can use parenthesis "()" in your code
second: Never use goto, not when you have subs and functions

sorry if it's a short answer but the goto question has been aswered many times in these forums - maybe search for "goto"

Most call it bracket although the correct term is parenthesis.


Usually (in most languages) and has a higher precedence level than or. However, DBpro has its very own (unpredictable) precedence rules. So my advice is: always use parenthesis in DB/pro.



There's no problem with goto if you only use it when really needed.

of i didnt know i could use them

I hate when people tell you not to do something "just because". Especially in programming. Okay, Goto's aren't that great, but you can get the job done with them too.. sometimes it's even easier with them.

Other thing I hate is that C++ coders generally hate BASIC, without even having a good reason for it! (some do, most don't)

Ok, here's my 2c on GOTO's.

When I first started commercial programming quite a number of years ago now, the guy I worked for said that using goto was ok so long as you only ever jumped to an exit point and only had one per routine. He was a *very* good programmer (as I now realise years after). As an example...

sub MySub
do some stuff
if stuff_didnt_work then goto exitpoint
do some other stuff
exitpoint:
return
endsub

The point is that you shouldn't over use goto's, if at all. It's not a cardinal sin to use them if you really have no other way but these days most people are able to code without using them. If your code isn't readable and you can't follow the flow easily then it's probably because you've used goto to jump all over the place. Even if you are the only one that'll ever read your code it's in your best interests to make it as obvious as possible so that in 6 months when you come back to it, you'll understand it quicker in order to enhance/fix it. If someone writes code in my company that isn't understood fairly quickly by another they aren't revered for being "clever" they are told to do it again. If they are repeat offenders, they are fired! Wehavenoroomforsmartarseswhothinkit'sclevertowriteawholeapplicationinonelineofcode!

In the above example most would replace the goto with return to exit the sub there and then. However if there was code after the exitpoint label say to tidy something up then being able to "goto" is of benefit.

Having said all that I would advocate use of if then else and nested if statements to avoid the need for the goto.

I normally don't try and tell people DO this or DON'T do that but goto is an exception.

Well there are two side to every coin. Some argue that goto's create none readable code, so by that token, Gosubs must also be never used. Now granted, you can indeed make some pretty unattractive code if Gotos are your only control. But programming is horses for courses.

When I was lad, structured procedural programming was becoming the 'way' all through high school. Ironically however, over the years things have loosened and languages today don't even reflect the 'one entry, one exit' that was once a strict design objective.

To put this into perspective, here's an simple example,

A common use of goto is to 'skip' to the exit/end of a sub as above. These days though, (in DBpro) EXIT, is the control of choice. Now the problem with the argument against goto's is that DBpro (and most basics) are anything but a well structured and easy to read to begin with.


a)



b)




Here's the anomaly. While Example 'A' is indeed the 'easier/cleaner' option on the programmer, it could easily be argued that it's the less readable of the two also, as EXIT has an unknown implied operation. In other words, just what exactly are we exiting here ?. The IF/THEN, The FOR/NEXT or even the sub ?.

Now obviously as DB programmers, we should all understand it through previous experience, but imagine it from 'new' programmers perspective. When I first saw an exit in DB, I asked this exact same question.. .

If dbpro was truly going for a more 'readable/structured' language, then we really should see Exit (For, Do,Repeat,While and IF) like other languages. So the control change can be implied explicitly.

Just stirring up the pigeons

ok, GOSUB uses RETURN it's not open ended like GOTO

(still reading your post...brb)

Code snippet A is the way to go imho. All code snippet b is doing is adding more uneeded execution do do the same thing, return execution to the caller.

also:

EXIT
This command allows you to break from a program loop at any time. Only control loops that have an
uncertain exit condition can use this command such as DO LOOP, WHILE and REPEAT loops. EXIT will have
no effect on GOTO loops during the running of your program.

SYNTAX
EXIT

also there is an EXITFUNCTION command

You can also do something like (This prints 0, if any of the variables is 1) :



although why you would want to do it is another matter...

i still dont understand why goto is so "frowned upon" these days. back when i used to write BASIC (version 1.0!) on the good 'ole amstrad you wouldnt have been able to live without goto!

i was just wondering, does goto use lots of cycles to process or something? does it have something to do with its "open-ended" nature?

personally, i think goto is a very handy command. its rare to find a code of mine without a goto in it somewhere

from my experience I find it's open ended nature to be the potential root of evil whenever you throw execution to somewhere in the code and it's done without gosub or function call, you run the risk of enexpected results. Maybe some condition you didn't think of happens and the goto gets all willy-nilly and ends you up somewhere bad - maybe it doesn't happen during development but during the demo for the customer or whomever...

nothing is 100% fool-proof, but I personally just feel better not using GOTO commands.

but hey, if that's what some people like - go for it!

i just figure that there are so many jump commands in the exe that one more isnt gonna hurt. but maybe a goto is more than just that.

i guess you're right about it being the root of all evil becoz if, for whatever reason, the wrong line number gets in there (dunno how) the program's definitely going to crash.

my theory: if its there, use it!

Your not interested in the output - you should only be interested in the source code. GOTO's produce spagetti code - hard to read and maintain.

Thanks for the refresher on EXIT, but after some 4 of 5 years of DB, i'm getting a handle on it.



Well, that's hardly a solid case for blanket condemnation of one over the other. There is no guarantee a label executed from a Gosub, will indeed return. It relies on the coder.

The problem with Goto / Gosubs is not the mechanisms, but their usages.




well, I'd choose A over B also.

However. So how have you've come to this execution analysis ?. Even If your assuming Loop structures are stack based at run time (which they're not), and hence an Exit is compiled as a 'pop pc' (pulling the previous PC off the stack) . It would still need to clean the stack up and then jump on the parent loops end address. While a goto is a absolute/pc relative jump.

I can't believe that even today, there seems to be this common myth that loop structures are stack based at run time. While I've never seen a Basic environment that works like that, there must be. Otherwise, why would it be such a common belief. Beats me.

Anyway, Exit/Continue etc are actually compile time smoke and mirrors. Believe it or not, Exit operations are compiled as jumps, same as goto's. So the position Goto shouldn't be used as it produces 'extra overhead', really doesn't hold water.

in my Do you want to quit? menu
if your mouse is over the "yes" button:


then there is a label, in another area, called quit


the reason there is a whole new label is that it will save right before the end command, and u probly will only be able to save while quitting

is there something wrong with this?

also another place with goto in my code

this was the camp window. it enables u to camp for a certain amount of days, having the world calculate all its stuff (gosub world) for a certain amount of time while the player is "camping"

also, if jumping>0then it goto's jumpmove (u move forward if u were moving forward when u started jump but u cant change ur direction) from there it goto's a label right after change direction commands but right before mouse commands, so u can look around.

i think there is nothing wrong with these goto's
i understand them perfectly and i think i will be able to later

@uwDesign:

this is the only quote you need...

Chris:

It's a question of style, if your conformable with your current approach, well why change for the sake of change ?. Nobody is forcing you too. Having said that, don't be afraid to step outside of the familiar and try new things. Some ideas you might like, some you may not. It's all part of the process.

Just looking at your code, there's a few things that come to mind that you might find easier, then again, maybe not too. The Goto's don't really bother me, what is more of a worry is the example seems to be largely 'hard coded'. If your not familiar with the term, it just refers to writing code that isn't very adaptable, when future chances may be required. In a small project, you can often get away with it, but as things get bigger, hardcoding generally creates more work for us, as we try to maintain/expand the old code..

So, while you might understand this code perfectly today, cast your mind ahead one, two, six months after you've finished this section. Now this is were readability really becomes an issue. You shouldn't need to re-learn how each part works, each time you need to update it.

One idea that can make things easier in the long run, is using meaningfully named variables or constants to represent Image Numbers, Sprite Numbers, Sounds, 3D objects, Positions, Colours. Anything Really. Names make the code easier to read, and providing you give them 'standard' names, it's becomes easier to remember also.

For example, while you might know what image 20 is today in your code, what about in 6 months time ?, or what if you you need to change this image number to say 500. Sure, you could manually go through all the code, looking for all the references to Image 20 and change them. But that'd be pretty painful right ?. So why not use a variable like this.

IMG_MenuBackDrop = 20
Paste Image IMG_MenuBackDrop,100,200
Paste Image IMG_MenuBackDrop,300,400
etc etc


So now every time you want to draw the Backdrop image, you'd use the variable instead of the number. The variable is really the image name now, if you think about it. Then if you ever need to change this images number, to 500 say (like in the above example), you'd just change the IMG_MenuBackDrop = 500 and that's it.

The key idea here is NOT to make variables that are really really really long and impossible to remember. Just short, sweet and meaningful as possible. So you or anybody and look at it and have a idea of what this variable is. Everybody pretty much develops their own naming convention as you go along. Personally, I try and make the variable names fairly descriptive if their important. I find this almost acts like commenting my code. So when i come back to section of code months later, a quick skim of the variables names generally gives me then gist of how it works.

For variables are only used calculates/loop indexes, I find it easier to use a things like LP,Xpos,Ypos, Result. Since these varuiable are changing all the time I don't really need to remember them, and their context and be easily understood.

i.e

For lp=0 to 100


next lp


You could use a 'more' meaningful LOOP counter name here, but it's generally not worth it, unless your nesting various loops inside loops.


Another point could be, If there's something about a section of code that needs to be remembered later, like a certain limitation that code may have or something you'd like to add perhaps. Then it's often best make a NOTE/ COMMENT about it in your code. I like to keep some breif tidbit comments about certain sections/functions/subroutines. Any major limitations/how to info, is then stored in the header of source. Again these are just so you when you return to the source, it's easier to understand, what it does.

While comments are useful, theres no point going overboard with them. not every line needs to be commented.

ie.





If can sometimes be helpful to underline Key comment though, so they stand out at a glance.






Anyway, back to variables as names. You can use the same idea for your menu positions also. This way, if you need to change the menu's order, position or expand the menu in some way, you'd just need to change the Variables that define where/ how your menu is set up. These kinds of ideas will make the code easier to expand and more flexible in the longer term. But, it can be a little painful to being with..



A couple of other things that come to mind, are some indentation, Arrays and functions.


Indentation. (Yes i know it may have lost it's indentation when you pasted to the board..) But Anyway, just in case, The idea here is make the 'flow' of the program more obvious at a glance. Admittedly, it's a style thing, it's not necessary to make a program work, or run better, it's just used as an idea to help us read the code more quickly and easily.. The idea is simple, rather than write all our code pressed up against the left hand margin, we'll indent (tab in) one tab any time we open a loop or and IF/then, or IF, Else, EndIF.. When the Loop/or FI then is closed, it tab back one level.

So, if this was some old code.




You might like to indent it like so..





It doesn't change the way the code works, it's just a bit cleaner to look at.


Functions.

If your not familiar with how functions work, there certainly worth the effort learning. Functions are a method of building your very own commands, you can choose the name, the parameters it uses, and even the variables it returns. These functions can be just about anything you like, they can be small or big. It's prolly best to start small, with simple functions, and get a handle on them. Generally, you'll create function to perform some type of calculation, or to clump a section of code all together, much like a sub rotuine. This will save you effort, and make your code simpler to write and understand.


I'm not going to even going to try and explain these in any detail. So here's a few function examples, try them out, once you feel confident, have a look through your program for 'common' elements that could be wedged/mades into a function. Then you call this bit of code, just with function name.. very useful













Anyway, getting back to your code, you could use a function to test if the mouse is without a certain region, in your case, if it over a particular menu item. Like this (bellow).. So then rather than having a whole like for code to check the mouse position, this way you get something a bit simpler and streamlined ..




Anyway, have a go and have fun.....

IIRC, on the old Apple 2 basic, the for/next construct used the same stack as gosub/return, but that's the only time I've encountered a shared stack for loops. I discovered this, because the stack was only about 10 levels deep.

The C64 used to as well, and I believe BBC BASIC on the RiscPC does too.

The Apple/BBc may well do, it's been a long time (almost 20 years) since I sat in front of one of those. But having tested the C64 before, it doesn't appear that Vic20/C64 basics stack For/Next tokens. You can check this yourself with followed couple of examples.

C64.

i.e. If the For pushes the counters info to the stack for the NEXT operation, skipping back should cause an overflow. but, if you run this, it will happily run forever.



However, if you gosub, and don't pop the return, it'll die from stack overflow as expected.




One possible explanation might be, the stack buffer is wrapping over and thus it's not being trapped correctly. However, if that was the case, it'd be unlikely the closed gosub would still work if the stack was corrupted like that.

The real test comes when you branch out of a for/next into another for/next using the same index.



and bingo, rather than do 10 cycles of 15 loops, it loops once.

As previously stated, this behavior *Must* have existed in some forms of basic to have established itself as such. It's interesting though, why it's 'still' considered such an issue today.

Indeed goto commands can sometimes improve the readability of code compared to exit commands, which are (internally) basically the same, as pointed out by Kevin.
Especially when there's not ExitFor/ExitWhile/ExitDo etc, or, like in JavaScript and other languages exit [label].
I've posted that on several occasions here: if you allow "Exit", you can't forbid "Goto". The most important thing is, make your code readable.