Of course you are free to write your code in any way you like - still it is best practice to follow at least some basic coding guidelines. Which ones apply, may differ a lot. So here only details important to HyperSQL will be explained.
Keywords and non-keywords
Whether uppercase, lowercase or mixed doesn't really matter for HyperSQL to identify objects - as for this task all comparision is done case insensitive. Still, common use has at least keywords written UPPERCASE - while others are not. These others may be lowercase or mixed, which is all up to you.
So if I just say it's all up to you - why to use that many words? There is a case where this is important for HyperSQL: Syntax highlighting. Keywords will only be identified if they are spelled UPPERCASE. I hope you don't mind me forcing you a bit to a clean coding style?
Put them in as much as you like and were you feel them convenient. A good idea is to use them to emphasize logical units (such as functions and procedures, or even loops and conditionals). But one place where you better not put them is in the middle of a declaration. Giving an example:
/** Synonym FOOUTIL for the function FOO.UTIL * @synonym fooutil * @author John Doe */ CREATE OR REPLACE SYNONYM fooutil FOR foo.util;
This is quite well formatted and easy to read. What I say - it's perfect to be processed by HyperSQL! But a bad habit would be to introduce additional line breaks after CREATE and after REPLACE - this would ensure HyperSQL to not recognize it (remember it processes your file linewise). So for HyperSQL, it is best to keep everything from CREATE up to the objects name on one line.
Again, case sensitivity does not matter. Nor do parenthesis e.g. around table names. Just the naming OWNER.OBJECT is currently not handled by HyperSQL - ├his may or may not be added in the future.
In general, this is not important - but there are special cases when packages come into play: As already noted, HyperSQL does no complete syntactical analyzis of the code - but simply walks it line by line, scanning for declarations. Thus elements of a package, say e.g. a function, is counted as member of the package last declared.
This means, if you would declare a stand-alone function following a package within the same file, HyperSQL would add it to the package. Sure that is wrong, but HyperSQL cannot tell this. So if you have to keep those objects within the same file, packages should come last after all other objects.
Even better organization would mean to spread objects over multiple files, as many/most larger projects are either do - up to the extent of having only one object (function, procedure, package…) per file.
Here it is much easier to tell objects apart, since they are usually encapsulated within separate units (<ProgramUnit> tags). Code within each unit, as you write it, should follow the other rules above (keywords, line breaks) though.
For more details on Oracle Forms, please see Usage/OracleForms.