Actujally, 3 cents:
(1) I like " _" in place of just "_". After all, underscore could be a valid
last letter of a variable name. The extra space or tab character prevents it from being interpreted as such. This method is used with several BASICs, and has the advantage that you mask out the quoted text and the comments, then search for the occurance of " _", and break the line at that point and join the next line to it. If that also ends in a " _", you
just repeat the process, as many times as necessary. It is a very simple parsing mechanism. Second, a number of programmers use this method
to add comments in innovative ways, since nothing after the " _" is handled by the compiler. So you could have the following:
:this is a comment _
and so is this _
and so is this.
You can even use it to align comments like this:
Code: Select all
_ this is a comment
_ and so is this
_ and so is this.
or you could use it this way: _ this is also a comment & line join
____________________ This starts a comment box ______________
_ this is a comment _
_ and so is this _
_ and so is this _
____________________ This ends a comment box _______________
In other words, you can get very creative with the use of the inderscore as a line join indicator.
(2) I tried to compile the purebasic.ide.pb program, but ran into some issues. I wanted to figure out where certain added capabilities could go. My idea is to do three things:
(a) extend the search to search each help in order -- PB, FASM, ASM, Win32, and so on. If it cannot find a match, it looks in other programs for declares, globals, and procedures that might match. Everything from the
PureBASIC root directory would be fair game for a search. Since a search could take a good while, I would attempt a crossreference index and also allow the search to be broken off if it runs too long.
(b) Use this technique to determine if a given file is a standalone executable, depends on terms, structures and constants found in any include files, and determine if it itself is subject to any include statements in any other programs. Again, crossreferencing would speed this process over time.
(c) Add a search for path for any include files, in case the PureBASIC tree on a target system differes from the source system. When there is more than one source, allow the user to designate, so that by a process of trial and error, the correct sequence can be established.
(d) Add a reformatting tool, so that source code can be optimized in
terms of readability. This would include such things as indent size, whether Case should indent further than Select and EndSelect, and whether code should have the main code first with Declares, followed by Procedures, or Procedures first. just for consistency. Line joins could be
inserted automatically to allow lines to wrap to fit within the IDE view window. It could also comment Next, Wend, and Until statements to make it easier to match to the original For, While, and Repeat stateents.
Technically, they might also be able to automatically tag comments to ElseIf, Else, and EndIf statements as well. This seems like overkill, but the ability could make it easier for someone to track up a long trail of statements to find the point of origin, or do down it to find the end.
But these are just to-do or would-be-nice ideas. The big one follows:
(3) HAVE THE COMPILER IGNORE EVERY DUPLICATE OF A DECLARE, STRUCTURE, OR CONSTANT. My point is that when you consolidate all your structures and constants together, you may have several secondary (include) as well as primary files pointed at that one reference. As long
as everything matches up in value or form, this should be tollerated and
ignored. When they don't match, the compiler should report that there is a conflict with a prior definition (different size, different fields, different
values for constants). XIncludeFile() ignores that a file was processed previously, but you still get the error on Structures that are redefined.
