Based on the assumption that user input is fully correct (i.e., no redundant spaces need to be handled), the formatting rules are as follows (based on QuickBASIC formatting conventions):
I. Cases Requiring Spaces
1. Spaces on Both Sides
Comparison operators: >=, <=, <>
Assignment compound operators: +=, -=, *=, /=, \=, ^=, &=, =>
Extended forms: +=>, -=>, *=>, /=>, \=>, ^=>, &=>
General operators: +, -, *, /, \, ^, &
Equals sign: = (assignment/comparison)
2. Keywords
If parsing is performed:
Function calls with return values should NOT have a space before (
Statement keywords SHOULD have a space before (
Examples:
if( → if (
line(0,0) → line (0, 0)
sin (x) → sin(x)
3. Punctuation: ,, :, ;
No space before, space after.
Examples:
a,b → a, b
a:b → a: b
a;b → a; b
4. Parentheses/Brackets/Braces
No spaces inside:
( ), [ ], { }
Examples:
func( a ) → func(a)
{ 1,2,3 } → {1, 2, 3}
II. Cases Requiring NO Spaces (Special Attention)
1. Unary Operators
Unary minus - should have NO space after it.
Example: -5 remains -5, not - 5
2. Base Prefix &
&H, &O, &B should have NO spaces after them, and letters should be uppercase.
Examples:
& HFF → &HFF
& O17 → &O17
3. Pointer Operator ->
No spaces before, after, or between - and >.
Example: a - > b → a->b
4. Compound Operators
No spaces inside compound operators, especially ternary forms:
+=, -=, *=, /=, \=, ^=, &=, =>
+=>, -=>, *=>, /=>, \=>, ^=>, &=>
Example: a=>b is correct; a= >b is incorrect.
III. Additional Guidelines
Fallback: If correct formatting cannot be guaranteed, keep the original as-is. Incorrectly added spaces may cause compilation failures.
Preserve original indentation:
Line-leading indentation
Continuation line indentation
Inline comment indentation
Maintain individual coding styles; only add spaces around operators and symbols where necessary.
Escape sequences: For "", !, and similar escape/control characters, extra spaces may sometimes need handling.
Legacy string functions (not required in FreeBASIC but syntactically valid):
chr$, str$, instr$
These should NOT become chr $(32) or similar.
Pointer dereference *:
Complex due to 2-level, 3-level, and multi-level pointer dereferencing.
Current handling is simplified based on the above rules.
If Tiko can perform parsing to distinguish pointer variables, determination becomes easier—based on the number of ptr levels.
Example: dim as byte ptr ptr ptr ptr ptr p — there are 5 * before p for dereferencing. (This is just a personal suggestion.)
The above formatting rules are compiled based on my personal understanding. I am still a beginner, so please bear with me if there are any inaccuracies. Your feedback and corrections are greatly appreciated!
Thanks - I have save this information into a notes file for myself. My plan is to expand on this idea a bit to allow a user to format a single line on ENTER, but also be able to "prettify" an entire file, or all files in a project. Of course this would all be driven by a user selected opt in setting. I would also like a popup dialog where settings for the pretty rules could be modified based on user's preference.
Additional points:
1.If considering compatibility with QB64PE or earlier BASIC dialects, metacommands such as $Dynamic, $Include, $Lang, $Static — when prefixed with Rem or ' — should be highlighted properly. Also, variable type suffix characters like %, &, #, ! (e.g., x%, y&, z#, a!) should not have a space inserted before them. These metacommands are typically used with the -lang qb or -lang fblite dialect. Please refer to the FreeBASIC Wiki sections: "Standard Data Type Limits" and "Metacommands".
2.a eqv= b is a binary operator, and there should be no space between eqv and =. Similarly: and=, or=, imp=, xor=, mod=, shl=, shr=. (For example, a and= b → a and = b.)
Your formatting notes are interesting and certainly useful for your own workflow.
However, it's important to remember that code formatting preferences vary widely between developers. What feels "correct" or "natural" to one person may feel distracting or even counter‑productive to someone else.
Because of this, any automatic formatting feature in Tiko should be optional and user‑configurable. A single fixed set of rules cannot satisfy everyone, especially when different BASIC dialects, coding styles, and personal habits are involved.
Your suggestions can definitely serve as a good starting point, but they should be treated as one possible style, not a universal standard. Ideally, Tiko will allow each user to choose the formatting rules that best match their own preferences.
I, personally, use "original case", that is: don't mess with I'm writing.
Quote from: José Roca on August 02, 2026, 09:27:50 AMBecause of this, any automatic formatting feature in Tiko should be optional and user‑configurable.
I agree 100%. The formatting options dialog that I am working on now is opt-in by the user. It will allow formatting the current line (after ENTER), format the current document, all open documents, or all documents in a project.
I also only use Original Case.
However, I am attempting to modify the scintilla lexer to allow ProperCase (ie Mixed Case) correctly. This has long been a sore point that I receive messages on. Will be nice to finally have it work correctly.
Quote from: Paul Squires on August 02, 2026, 10:45:14 AMHowever, I am attempting to modify the scintilla lexer to allow ProperCase (ie Mixed Case) correctly. This has long been a sore point that I receive messages on. Will be nice to finally have it work correctly.
This is now fixed (finally!). The Scintilla and Lexilla sources have been modified along with Tiko's built in lexer to load keywords using ProperCase format. So, now all casing can work correctly: lowercase, UPPERCASE, ProperCase, and of course original case.
The new Format functionality is now implemented. Looks good and seems to work well from my initial testing.
I have attached some screenshots.
Here is the other screenshots