Allow { } to be used as an alternative to BEGIN END
{
a = b
c = d
e = f
}
Is more readable than
begin
a = b
c = d
e = f
end
In the same way we use <, > and ! operators instead of .lt. .gt. and.not., it would be nice to use { } instead of BEGIN-END
Happy if it was only in synergy.net
"Files":
begin
begin
"FileDefinition": "CUSTOMERS",
"InputFile": "DAT:customers.ism",
"OutputFile": "SCRUBBED:customers.ism",
"Overwrite": true
end
begin
"FileDefinition": "ITEMS",
"InputFile": "DAT:items.ism",
"OutputFile": "SCRUBBED:items.ism",
"Overwrite": true
end
end
(Only joking)
11/8/2019 10:27 AM 0
I think the preference of { } over BEGIN END depends on the languages you've come from. Java/JavaScript/C# do prefer the curly braces, but Basic/SQL and others do like the BEGIN END method.
Also, I think curly braces are used for attribute marking with Synergy.NET (though I may be wrong).
11/11/2019 9:49 AM 0
1/8/2020 7:18 PM 0
1/10/2020 2:36 PM 0
Having considered this request we wanted to be up front with you all and tell you that we have decided not to implement this change, for several reasons that I will now attempt to explain.
We know that some languages use braces for their block syntax, but (as pointed out by Mark) there are many examples of languages that use a variety of other block syntax; at least eight of which (including Pascal and Ruby) use BEGIN/END.
DBL started life as a DIBOL-compatible language, became a superset of and ultimately replaced DIBOL. We’re proud of our DIBOL heritage (an ANSI Standard language by the way), where the block syntax is BEGIN/END.
Gordon states brace syntax is more readable than the BEGIN/END, but honestly we feel that’s pretty subjective. Having talked with various people it seems that people are pretty much split on that one. I personally don’t find a difference in readability; I feel that what really impacts readability is non adherence to established coding standards, and the lack of in code documentation comments.
Also pointed out by Mark, braces already have several other uses in DBL:
- In Synergy .NET braces are used to delimit attributes, and we’re planning on extending that support to traditional Synergy soon.
- In traditional Synergy attributes are already supported in a limited way in xfServerPlus methods; they make it possible to auto-populate the Synergy Method Catalog by using the DBL2XML utility.
- In Synergy .NET braces are used to delimit the body of in-line lambdas:
- Braces are also used to delimit object and collection initializer lists:
In both of the IDE’s that are commonly used with DBL (Visual Studio and Workbench) the process of inserting a new block can be accelerated significantly. In Visual Studio there is a BEGIN snippet that means it takes just 4 key-strokes to insert a block, and position your cursor inside the block and indented to your preference. And in Workbench you can easily add an alias, perhaps “be” (for BEGIN/END) which only requires three key-strokes to do the same thing. Workbench wins, by one key-stroke!
The use case with in-line lambdas would be particularly challenging to resolve. I won’t use the “I” word (impossible), but it would require extensive effort in the compiler.
What this really boils down to is that we just don’t see any significant ROI that would support making this change, and we mean for YOU, not for us. In the time it would take us to re-work the compiler to allow you to use braces instead of BEGIN/END, a change that honestly would produce nothing in terms of enhanced capabilities or business benefits, we can achieve so many other things. Things that actually extend your capabilities when working with the language. Things that will help you work more productively, more accurately, and extend the capabilities of your products.
We hope that you will agree with us on this. We exist to provide first-rate development tools to all of you, and we don’t like saying no, but on this occasion that’s the answer. We hope you will understand.
1/23/2020 10:52 PM 0
If we can't get productivity from reducing the need to type BEGIN/END blocks can we at least get some type of static analysis or roslyn code fixer-like ability to address areas where developers were too lazy to explicitly type BEING/END? This is the source of countless bugs:
if (true) then begin nop end else nop nop ;BUG BUG If the Developer intended to have this in the else
In CSharp with StyleCop this throws SA1520 https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1520.md
1/24/2020 2:36 PM 0