Variable v's Fixed Value

[Dimster]

@MasterGy ... Garland of Pearls is terrific. In going over the code I notice the use of a variable rather than a fixed value in the math formula. For example the variable ZOOM appears to be a constant 2 and the Name ZOOM is used in the math formula for x1,y1,x2,y2, rather than the fixed value of 2.

Whereas in the case of the variable POWER, it's value is not fixed and the math formula vec_x and vec_y also use the variable POWER.

The POWER application seems to me to be the way I mostly see named variables used. I was just wondering if you find some advantage in your coding to use named variables of fixed values for use in formulas ?

[Pete]

@Dimster I hardly ever use constants. From the old days, it was a way to save that coveted stack space. This is because a constant is compiled with less allocated space, since the compiler knows it won't be changing in value. Those days are behind us, so this type of optimization is now more of a coding preference than a necessity for large applications. Readability is somewhat an advantage to constants. The programmer, or someone else studying the code, is informed of the variables which are fixed. No need to track them when debugging. For coders who have a hard time keeping things straight, constants prevent the mistake of taking a non declared variable, meant to be a constant, and mistakenly assigning it a new value, someplace in the code. That's called OOPs programming!

I'm interested to seeing MasterGy's reply to your question, as well. It's great to get other coders perspectives on coding style. Something we should probably discuss more on these forums. Great question!

Pete

[MasterGy]

I'm sorry, I just saw the question, I was very busy for a few days.
In the program, the ZOOM variable only means how many times the coordinate points are multiplied to show well on the screen. The higher the magnification.
POWER is a repulsive or attractive force created by the connection of two points.
Fixed or fixed values? I prefer something to be associated with something. For example, I like to clarify the screen size with MONX, MONY at the beginning of the program, because when I place an object on the screen, I always specify it in proportion. If I want it to be roughly at the bottom left of the screen, but not in the corner, I specify that the image be MONX x .1 and MONY x .8 (example only) and MONX / 10 x MONX / 10- and size. So anytime, any time I resize the window, the position of the image will follow proportionally. That was just one example. I don't like fixed values.

[Dimster]

Code: QB64: [Select]

1. x=Cent_x + obj(a,0) * zoom

v's

Code: QB64: [Select]

1. x=Cent_x + obj(a,0) * 2

I see it. By putting a name to the value of 2 you do get a better picture of the intent of the formula. Because it is however a "variable" do you have some trick that you use to be sure "zoom" doesn't change in value?

[SMcNeill]

Because it is however a "variable" do you have some trick that you use to be sure "zoom" doesn't change in value?

Make it a CONST.

Const Zoom = 2

[Dimster]

Hi Steve... ya. @MasterGy doesn't seem to use CONST, so I was thinking he may have a method whereby he comes up with a quasi CONST. So something like, if the value in the formula will never change then rather than use CONST, just use the fixed value (ie use a 2 instead of the variable zoom). Where there is a constant change in a value, like his POWER, then the obvious benefit of a named variable works for this case. But, where you want to see the full run of your program with the flexible POWER but in the 2nd run you want to alter only the zoom. Therefore he would need to somehow keep track of which variables he wants to change per run and which he wants to keep their fixed value every run.  A variable named A, or B or FN etc may be difficult to id as your quasi CONST, whereas a variable named zoom can clearly be found.

I haven't used variables as a quasi CONST. The thought just struck me when I was looking over @MasterGy 's code. And I think @bplus was alluding to simply changing CONST values in multiple run throughs. I assume he has a distinct name for his CONSTs

I don't use CONST and my naming of variables tend to be on the longish descriptive side. I'm not sure what kind of trouble I can get into if I include quasi CONST like zoom. Now in my case, where I have a head like a sieve so a simple zoom would not suffice, it would have to be Qzoom or Quasiz.

[SMcNeill]

I've seen "Quasi-Constants" in use before.  In fact, QB64 itself has some.  If you look in the internal directory, you'll see our config.ini file.  It has a whole list of quasi-constants which we make use of.  For example, we have: TextColor=_RGB32(216, 216, 216).

TextColor is <almost> a CONST in the fact that even though it's used constantly inside our program, the value can really only be changed via one specific user action -- Menu, Options, IDE Colors.  At no point do we assign a value to it anywhere else inside the code, besides that one specific spot, even though we might read that value and use it in multiple modules.

Being able to call Color TextColor or Color BackgroundColor or Color QuoteColor is much easier to use and keep up with than trying to remember Color 4, 7, 11 for those 3 values (if that's even what they actually map to.  I'd have to look them up to be certain now, since we use the variable names internally and not the values themselves.)

They're used similar to CONST, with the exception that they *can* be changed -- but only in the proper condition and usage.  Does that make them "quasi-Const"?

[MasterGy]

I actually use "CONST" if I want to see sub / function as well. In cases like "zoom" I leave. Because I might be thinking one and adding 1 line to the program that works with the "zoom" value. I don’t limit myself unnecessarily and I don’t put anything in it that I don’t have to.