This is what getting old is like for me...

[Pete]

I used to make single letter variables in QB45, to save memory. I had a few hundred variable names in some larger apps, and I honestly could remember what each one represented. Towards the end of the QB era, I made a cheat (hash) sheet, as it was getting a little hard to instantly recall those same variable letters. When QB64 came along, I slowly started naming variables, first as single words, and then a few years back, I started using compound words to make understanding the function easier. Now, I find myself wanting to do something like this...

a$ = "replace_decimal_point"
replace_decimal_point$ = a$
replace.decimal.point$ = a$
GOSUB replace_decimal_point
END

replace_decimal_point:
PRINT a$
PRINT replace_decimal_point$
PRINT replace.decimal.point$
RETURN

instead of...

a$ = "replacedecimalpoint"
replacedecimalpoint$ = a$
replacedecimalpoint$ = a$
GOSUB replacedecimalpoint
END

replacedecimalpoint:
PRINT a$
PRINT replacedecimalpoint$
PRINT replacedecimalpoint$
RETURN

Easier to site read with underscores or dots, right? Well, since I've never used this type of naming, I was not surprised the underscores were accepted, but I thought dots would have been reserved for TYPE defined variables. I'll probably go with he underscores, just to avoid that confusion when sharing code.

Comments welcomed, unless it's about my age... then $%^&_OFF.

Pete

[FellippeHeitor]

I usually go with camel case for naming my variables. Same for procedures and custom types, but then I start with a capital letter as well:

TYPE Object
    x AS SINGLE
    y AS SINGLE
END TYPE

DIM object(1000) AS Object

replaceDecimalPoint$ = a$

DoReplacements

SUB DoReplacements

END SUB

[Pete]

Camel case? What, you only code on Wednesdays?

Kidding aside, I'm an unconventional typist, and I avoid mixing case as it tends to slow my coding speed down. It's a good method for readability. It is especially good for displaying domain names like: dialupass.com or sandhillsexpress.com... DialUpAss and SandHillSexPress, right? Oh well, like I said, it messes with my typing.

I have entertained using TYPE. One thing I like is that reusable subs and functions can just have one variable nae associated with the TYPE like: decimal_tracker. So decimal_track.x, decimal_track.y, etc. The TYPE definition is the hash table, so to speak. This makes the odds of duplicating a variable in other modules you associate these"library" routines virtually null; especially if you use global variables.

So...

Code: QB64: [Select]

1. TYPE Object
2.     x AS STRING
3.     y AS INTEGER
4. END TYPE
5.  
6. DIM SHARED replace_decimal_point(1000) AS Object
7.  
8. replace_decimal_point(1).x = "3.14159"
9. replace_decimal_point(1).y = INSTR(replace_decimal_point(1).x, ".")
10.  
11. do_replace_decimal_point
12.  
13. SUB do_replace_decimal_point
14. PRINT "Number: "; replace_decimal_point(1).x, "Decimal place at:"; replace_decimal_point(1).y
15. END SUB

Now I would use GOSUB instead of a sub call, just so the library routine only shows up as a single sub, but...

If I did want to use a sub call, how would the variable, in the example above, get passed to the sub without DIM SHARED?

Pete

[SMcNeill]

SUB do_replace_decimal_point (whatever AS Object)

Then you pass the variable via whatever.


SUB do_replace_decimal_point (whatever() AS Object)

Then you pass the whole array via whatever().


SUB do_replace_decimal_point (whatever() AS Object, index AS LONG)

Then you pass the array via whatever(), and use the index to track the specific index you want to work with.

[Pete]

Cool, thanks! I don't know if I'll get into it much, but I do have to start making some changes if I want to squeak out a few more years of coding. That darn string math thing I'm working on is going to be around 500 lines. I'll probably give the TYPE style a shot on something smaller.

Code: QB64: [Select]

1. TYPE Object
2.     x AS STRING
3.     y AS INTEGER
4. END TYPE
5.  
6. DIM replace_decimal_point(1000) AS Object
7.  
8. replace_decimal_point(1).x = "3.14159"
9. replace_decimal_point(1).y = INSTR(replace_decimal_point(1).x, ".")
10.  
11. do_replace_decimal_point replace_decimal_point()
12.  
13. SUB do_replace_decimal_point (replace_decimal_point() AS Object)
14. PRINT "Number: "; replace_decimal_point(1).x, "Decimal place at:"; replace_decimal_point(1).y
15. END SUB

Pete

[Richard Frost]

Your code has convinced me to avoid using floating point numbers, forever. 

Please petition your local politician to make pi equal to 3 to assist me in my new quest.

[Pete]

Please petition your local politician to make pi equal to 3 to assist me in my new quest.

Unfortunately, my local politician is a Democrat, and he can't count that high.

Pete :D

[Cobalt]

Unfortunately, my local politician is a Democrat, and he can't count that high.

Pete :D

if you had a Democrat and a Republican and as them to count as high as they could, how high would they count?


They wouldn't even get to 1 cause they would never stop arguing where to start.

DIM SHARED Poly_Ticks(537) AS _BYTE 'They sure DO!

I tend use the Underscored Camel Case anymore myself. Now if I'm trying to make a SUB or FUNCTION that I may use in more than one program I will typically use short generic naming, sometimes even single letter.

[Jack002]

Everyone knows what the opposite of PROgress is....