Using periods in sub and function names?

[TerryRitchie]

I noticed this can be done:

FUNCTION MY.NEW.FUNCTION()

    - code here

    MY.NEW.FUNCTION = -1

END FUNCTION

I saw the use of periods as word separators in someone else's code. I decided to use this construct on a project I'm working on. However, as the code grows (up to 4000 lines now) the IDE sometime fails to color code the SUBS and FUNCTIONS that use periods in their names. I need to move the cursor by pressing the space bar (or simply typing) and the color coding will come back, but disappear later again.

Is the IDE doing this because it does not like the use of periods in the SUB and FUNCTION names? Should I not be using this construct? I find it to be much cleaner looking than MY_NEW_FUNCTION but can revert to this if need be.

I've not run into a problem with the code compiling or running in any way, just curious behavior from the IDE I've noticed, especially like I said as the code continues to grow and only affecting SUBs and FUNCTIONs with periods in their name.

[mnrvovrfc]

Syntax coloring is nearly impossible to get at the user's satisfaction. There are too many possibilities to cover. This is shown well by NPPP as well as the popular text editors for Linux such as Gedit and Kate.

The QB64 IDE occasionally becomes confused with what it thinks are keywords that it should highlight or not highlight. It's difficult to predict where an user would write something somewhere in the code. Add to that the fact that many "statements" in BASIC could also be functions, and some "functions" could exist on LHS, MID$() being a prime example.

Personally I don't like using periods to name subprograms, and I wish there was a "WITH" like Pascal, not like Freebasic which allows the dots to hang in the front of field names, that could otherwise avoid the typing of "variable-dot-field".

Might be that the IDE has logic to take "dot-name" always as a field name from an UDT, and therefore it has to be "trained" to check out which names could be fields. "dot-name-dot-name" could be easily checked if the program has no UDT's but that's kind of difficult in a major project.

[CharlieJV]

To me, periods are visual cues that I'm dealing with a variable that is of a compound type.

If I were working with a program with sub/function names that had periods in them, I would be immediately annoyed by the "semantic-meaning-overloading" of the period mark.

[James D Jarvis]

I wouldn't use the periods in the function names myself even if the compiler doesn't bark. To me they look like records or methods being used.

[bplus]

I wouldn't use the periods in the function names myself even if the compiler doesn't bark. To me they look like records or methods being used.

+1 Nor do I, save periods for UDT's.

I don't particularly care for underlines but that is because more typing. I would say if you don't like camelTyping (or MountainRanges) use under_line for word separations. They do fill in for spaces quite nicely.

But Terry might be reporting a bug which might need fixing.

[TerryRitchie]

Yes, they do resemble UDTs and that would get confusing to someone viewing the code. I'll stick with either camel case or underscores then.

I didn't consider this might be a bug. I was always under the impression that SUB and FUNCTION naming followed the same convention as variable naming. Perhaps this is something that needs further investigation.

Thanks for the replies guys.

[SMcNeill]

The coloring coming and going is a basic issue of how Galleon designed our IDE.  Instead of drawing on a single image screen, Galleon choose to use multiple pages for the IDE.  Page 0 is the active screen.  1 is a background page for your text.  2 is the IDE help area (IIRC).  3 is the menu/borders...  All of which goes back 20 years ago to the original roots of QB64 when it was being built and compiled in qb45 and wasn't a self compiling programming language.  Back in those days, there wasn't any _DISPLAY to sync pages to an users monitor's display rates, so to prevent that annoying "flicker" that you'll find with looped routines, Galleon made use of page flipping.

Draw on page 1 until finished.  Then PCOPY 1, 0 so it's visible to the user...   <-- Old Skool page flipping at work!

The issue here is that over the years, we've worked to add some extra color into the IDE for keywords and functions and all.  Apparently, one of those many multiple pages got missed with the logic which colorizes those keywords.  Page 3 (or whichever it is) isn't properly coded to color My.Function.Foo properly, like Page 0 might be.  <-- This is where the issue comes from that Terry reported in his opening post: "I need to move the cursor by pressing the space bar (or simply typing) and the color coding will come back, but disappear later again."

What's happening here is one page isn't coloring the code.  Another page is.  And, as you type, those pages get PCOPYed across to each other leading to this "it's colored... wait... now its not... oh wait... now it is..." syndrome.  

It's a glitch in the code, but now the question becomes:  WHERE in the code?  And on which Page?  And can we **EVER** find it and correct it?  The issue isn't even as simple as doing a search for _DEST or _SOURCE and to dig for the problem.  The issue, as I mentioned above, dates back to the QB45 roots of our project -- someone will need to figure out which SCREEN , ,var1,var2 command is relevant and then sort out the glitch in that page not coloring a Dot.Name.Function properly.

In other words, I wouldn't hold my breath for a solution -- this isn't the sort of glitch that is easily found, so it's not one that's going to be easily fixed.  (Unless someone just gets very lucky, IMHO and stumbles upon the proper area to put a COLOR 3,7 statement into the code.)

Fix here isn't hard, I don't imagine.  FINDING *where* to make the fix -- that's what's going to be a real PITA. 

[bplus]

Hey was that interesting or am I just that bored. I like these historical notes of Steve, specially when they apply to these oddities we find.

[SpriggsySpriggs]

I've used periods before when writing functions that would emulate ones found in an object-oriented language. I see their purpose and I have no issue with such naming scheme.

[TerryRitchie]

I've used periods before when writing functions that would emulate ones found in an object-oriented language. I see their purpose and I have no issue with such naming scheme.

That was my thinking for using them as well. On another note, I just finished renaming all my functions and subroutines with underscores in place of the periods and the color coding anomaly I mentioned disappeared. It seems using periods in function and subroutine names brings out the issue Steve mentioned above more easily. Perhaps a clue on where to look?