Sorry your browser is not supported!

I know a few do, but this is something that came to mind recently after observing a number snippets. I have always used constants as variables that do not change; but they are more than that in DBPRO.

Constants tell the compiler to replace a constant name with literal code; the code can be a calculation, a series of function calls, text, data or a series of keywords.

Does anybody use it to insert an entire line of code without having to retype it? I have not.

This is not me trying to encourage laziness; I am just curious if anybody is doing it, because it appears to make sense, why not tell the computer how to do something instead of just telling it what to do. Something like



So you end up with something like this when you simply need to query a list of something common like a player:



This is a more tidier way to read something like this:


Both snippets do the same thing. It seems like a cool way to insert your own snippets, but needs discipline to make sure the snippets are clean and correct; it is almost like creating keywords; something regular functions could not achieve with local variables (Although my example is working with globals)

Another example is used in Diggseys TopGUI, where GEN_ID is an easier term to write than INDEX_ID(0). Another example is GAME_TIME$ rather than GameTime$( CurrentDay, CurrentHour, CurrentMinute).

Updating the constant is always easier than updating literals; and the advantage over functions is that you can engineer your own branch statements using a series of regular branch statements that work with the UDT, memblock, bank, net packet or what ever it is the block of code is for. You can update such things in one place and not have to repeat yourself as much.

Perhaps someone who has practiced this over a long time is aware of any disadvantages...

I've never used "#CONSTANT"'s in DBPro yet, but I have always had the need of them especially in assembler and sometimes in C. I guess it's something I've not thought about for Basic though.

That's a nice touch though you've put there and it does make it readable and less prone to typos too.

I agree - and thanks for the reminder that we can do things like that.

One issue with using constants is you can not use any reserved word as a constant.
The dbpro compiler parses constants out of Dbpro command words. This could cause
confusing bugs for some.

I reference this post.

http://forum.thegamecreators.com/?m=forum_view&t=190800&b=7

[img][/img]

I tried it a long time ago, but my code was much harder to read when returning to it later.

That's my opinion on it too TBH - it hides too much code when you do anything that has more than a single effect.

Yeah I remember posting in that thread. There are already more constants in my code than globals anyway, and I never get any trouble with reserved words because I prefix most things; I do not like to worry about conflictung names, I do not want to have to check things like that.





I can imagine. Sticking to the single effect, I will give it a go with specific purpose snippets that get used everyday, at least after more careful consideration. I also do not like hidden code, most of my bugs build up in hidden places; just like at home...

I am already guilty of using functions for single line shortcuts anyway; with constants, single line expressions that are better described with words could be used.

The real reason this interested me is because I use arrays to store text to be altered according to language; at first I was using constants for indexes; but now I am creating constants for the whole reference aswell as the index for other uses:

Before code:


after:


It looks lazy when you look at it here, but it does make a difference when dealing with 1000s of reused phrases and sentences.

Since the array has specific purposes for each index; I can refer to them by name without having to also fetch a global index value; providing I feel the term is going to get used regularly enough to warrant the extra declaration. No need for parenthesises in parameterless functions and I can change what ever constants like TX_EDIT_PROMPT is refering to in future nice and easily. It will throw an error if I do a typo; which sadly, I often do, thus no invalid array index worries for me.

@BatVink+IanM

On reflection I think you're probably right.