I saw the “official” Oxygene libs released by RemObjects keeps “begin” of the same line
for ..... do begin
end;
if ..... then begin
end else begin
end;
I wonder if there is any official guideline for Oxygene coding styles?
1 Like
I have my own coding style (Delphi) but sometimes I really appreciate C# automatic formatting 
Maybe you can add a formatting tool for Water?
Official style is
for ..... do begin
end;
if ..... then begin
end
else begin
end;
but I’m having a hard time getting certain people to pay attention to always adhering to it, when they are in a rush ;). The most consistent code base you’ll probably find is EBuild, as I’ll fix all bad contributions that arent mine, there 
I’ve started working on style guide for the docs site a while back, but haven’t gotten around to finishing it. here’s what I have so far:
This document aims at providing a style guide for how to structure and format code written in the Oxygene language.
The guidelines laid out here are by no means mandatory, and an Oxygene developer may choose to adopt all, some, or none of the guidelines provided. However, our IDEs are designed to work best when code follows the guidelines, and we try to adhere to these guidelines for all code in Elements and its surrounding libraries, ourselves. Code submissions and pull requests for the open-source Elements libraries must meet these guidelines, as well.
Keywords
- All keywords shall be used in their lowercase form.
- Use the
methodkeyword instead ofprocedureorfunction. - Use the
blockkeyword instead ofdelegate,method,procedureorfunction, for Block declarations. - Use the
namespacekeyword instead ofunit, at the beginning of a file.
Casing & Naming Conventions
While Oxygene is case insensitive, it by default preserves case and warns when identifiers differ in case between their declaration and use. These warnings should be avoided, and care should be taken to use the proper case. We recommend enabling Auto-Fix for case issues.
- All keywords shall be used in their lowercase form.
-
Type names should use a PascalCase form, without the
Tprefix common in other Pascal dialects. Upper-case abbreviation prefixes should also be avoided — use Namespaces instead. -
Interface types should use an
Iprefix, followed by a PascalCased name. - Public type Members (that should exclude fields) should use PascalCase names unless the platform conventions for a single-platform project suggest otherwise.
- Variables usually use a single-letter lower-case prefix, followed by a PascalCase name:
-
Fields should use an
fprefix:fName -
Local Variables should use an
lprefix:lName - Loop or very short-lived helpers variables may use short, lowercase names:
i,x - Parameters should use an
aprefix:aName
Spacing
Code Structure
If an if uses a begin/end block, any connected else clause must also use begin/end, and vice versa. In other words, an if clause with a block should not be mixed with a single-statement else clause, or vice versa.
If an if, else statement, for, while or similar statement does not uses a begin/end block, the then keyword should always be followed by a linebreak and the following statement should be indented in a new line.
2 Likes
Water should already format on Paste (unless you turned that off in Preferences), and you can reformat the current selection or the while file via Reformat in the Edit menu?
This is exactly I am looking for. Thank you, and I like it - doing things in the right and official way gives me peace and comfort. I always try to stick to certain coding styles, mine or an established one.
RemObjects SDK Delphi’s source code has inconsistent coding style - and reading it sometimes really makes me going nuts.
PS . Maybe Visual Studio can have a formatter too but I guess I can always use Water to do the formatting.
I’ll try to get it more complete and published, sometime really soon.
@EvgenyK something to look at and clean up as we go.
I believe formatting is exposed in VS too, yes. Not sure what the menu is, right now, as I don’t have a local VS install to check.
Hi,
In Delphi (EW/ROD/DAD/HYD), I also use this style:
for ..... do begin
end;
if ..... then begin
end
else begin
end;
but some old code still use wrong formatting.
I fix it when I work with that code.
2 Likes
For .NET naming conventions, and other things, there exists the following book: Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 3rd Edition [Book] (oreilly.com)
If you need to create a .NET library that will be used by others, this is a very good read.
1 Like
Fiest draft: Oxygene Code Style Guide
good idea, I’ll add a section about platform naming conventions.
I wish there was a way of have begin on a new line because thats what I use. I just go through any generated code and fix it myself.
To put in my two cents:
The unbalanced syntax of PASCAL always lead to contrary discussions about the “correct” way to format the code. I remember that we had one person at ETH who had his own maybe strange opinion. He always started to write the first statement on the same line, right after the begin.
By the way, it was Niklaus Wirth, the father of PASCAL.
2 Likes
IIRC he used upper-case keywords, too, so what does he know… ;).
You can, of course, manually ;). If you’re an animal.
i can see if I can add affordances for that in Fire/Water for keyword completion & the like. I’m not sure what I can do for templates. Our code formatted right now is singe-line (i.e. it will never join or split lines, it will just indent each line to match what came before); else we could just run that over all code from template — but it won’t help you… (I could make it uppercase keywords though, I suppose, when that option is checked)
The CDC 6600 was a 60 bit computer (Seymour Cray) and a character had 6 bits. So there were only upper-case characters anyway 
1 Like
Another coding style question is - so we wrap long line?
I saw in RemObjects official Oxygene code, long lines are not wrapped at 80th column ( actually, no wrapping at all)
I wrap long lines manually, sometimes. Depends on context, complexity and readability. I’m not a fan of automatic wrapping done by the code editor (like Xcode does, optionally). Fire/Water has some support for this, eg if you press enter inside a (, it will try to indent properly to match the right indent for the matching (, eg:
SomeMethodCall(a, (more code here),
b,
c);
Right now i have no concrete guidelines for how to do the wrapping, its mostly gut-feel; suggestions welcome.
I do the same, but sometimes not sure but you confirmed with your guru opinion.
Generally I try to keep the line shorter than 118 columns (for easy read and review using GitHub iOS client), and methods less than 60 lines.
I enjoy reading code that is well formatted and structurally clean — appreciating the aesthetics of structure, abstraction, and logic.
i don’t have exact numbers for this, I generally ap[ply an “I’ll know it when I see it” approach to deciding what’s too much, both for line length and for method size…
Yes!
can you specify what units has bad coding style, pls?
Hi Evengy, thank you for following up. It is nothing serious, just very minor inconsistency issues (in my subjective view) here and there:
- Fields have mixed use of
fFieldNameandFFieldName - simple
if .... thensometimes user one liner, sometimes break into two lines - methods arguments, mixed use of
aArgName, AArgName, ArgName - local variables, mixed use of
VarName, varName, lVarName - Inconsistent names of primitive types:
integer/Integer, boolean/Boolean, string/Stringetc
It would be nice to have a unified and consistent coding style throughout. But I understand ROSDK/Delphi has so many legacy codes, probably it is not easy to do so.