Opinion on Syntax of a procedure

[waldo1001]

The current syntax for a simple function is this

local procedure TestMessage2();
begin
    message('Published event Event is working!')                
end;

Why is there a semicolon after the procedure. this feels really bad while coding.
also, I'd rather have no "begin" and "end". lots of statements work with { }. something like this is makes more sense to me:

local procedure TestMessage2()
{
    message('Published event Event is working!')                
}

... just my opinion

[TheDenSter]

I agree, the semicolon is confusing there, and {} makes more sense than begin-end, especially with lower case vs upper case

[Gallimathias]

This is my opinion too, and I had already made it as a issue and got a short answer from StanislawStempin Issue 48. If, however, more of the opinion are, MS should also think more about it

I also agree the semicolon is confusing. However, my opinion is the current syntax is a bit inconsistent between begin/end and {/}.

Why not replacing begin/end for usual AL blocks?
if condition then { doSomething() }

... just my opinion :)

[luxzeitlos]

Another way could be to replace the ; with an : which would make more sense:

local procedure TestMessage2():
begin
    message('Published event Event is working!')                
end;

Also I want to mention that the ; is not consistent with classic C/AL where ; is a statement seperator.

[Gallimathias]

So we're getting begin and end must go. I'm just doing a workaround to find the way to fix this without MS.

And the damn semicolon I will surely somehow get away.

local procedure TestMessage2()
{
  message('Published event Event is working!');                
}

What annoy me synonymous still are the semicolons as a separator for parameters. You can not just take commas like the rest of the world. No, we need semicolons for unfathomable reasons. Please use the semicolon as other languages. Under Stay tuned it out with the .NET guys.

[ajkauffmann]

From several trainings about AL and VS Code I got the same response from people:

• Remove the semicolon after the function
• Use curly brackets instead of begin...end (at least for procedure)
• Use comma as separator for parameters, field properties, etc.

Feels far more natural, I have made so many times mistakes here, typing a comma where the language want a semicolon.

[waldo1001]

I have the same feedback from people in my trainings..

[StanislawStempin]

In July Update the semicolon after method/trigger has been made optional.

[Gallimathias]

This is a damn good news. I will ensure that in our rules the semicolon is banned on the spot. I love the decision now :D. Let's tackle the next issue.

[Gallimathias]

@StanislawStempin
Ok sorry again for the double issue #645.
I'm trying to explain my point of view on the subject of brackets without the I love C# argument :D.

Point one is the consequence in AL itself. Currently, four symbols are used to declare blocks: BEGIN END {}. However, in my opinion, the rule does not clearly define when which symbol is valid.
We see that layouts, classes, areas, groups, fields, actions using parentheses have a break in the syntax if the methods use begin end at once. This is especially confusing for beginners. Because what's the rule:"Anything but methods uses {}?" Why do you use two different symbols? Why wasn't one of the two variants chosen?

The second point is a psychological one. Symbols always work better than text because our human brain is designed for it. A word consists of several symbols. at begin of four b, e, g, i, n. All four symbols have to be processed individually by the brain and then recognized as a context. If the result is in a foreign language, we translate it unintentionally. Certainly all processes in the subconscious mind, but that's why people always find symbols more pleasant than texts.

Then there is the fact that a single symbol is not only recognized faster, but we also automatically associate a meaning with it. In the case of parentheses, we know that they are bracketed. This works even better when people are through school and massively tormented by mathematics ;). In addition, the parentheses have a deeper effect on the recognition of parentheses, and I am now saying that most of the popular and widely used languages use parentheses as block syntax.

In addition, the begin and end are highlighted with the same color as other expressions. Since the words are wider than a parenthesis, for example, this seems to us to be more massiv. With a lot of code there are no breaks and interruptions for the eye, which makes the code look messy and messy because we have the feeling of a massive text block. It's strenuous reading.

The third point is a completely practical forklift. A bracket is much easier to identify and search for. Since special characters, especially parentheses, are not allowed in identifiers, their meaning is always unique. A begin end, on the other hand, could also be the part of a word. OnBeginReading, OnValidatingEnds etc.....
And it should be easier for you in the transcompiler to recognize the parentheses instead of an begin and end.

I would also like to mention that we will do a lot with web in the future. This means that JSON and JavaScript become an important part of the NAV every day or are already an important part of it. However, brackets are also used there. A more frequent change is easier for me if certain things like blocks are identical to each other and I don't have to remember any exceptions in expressions.

 trigger OnAction();
                var
                    test : Text;
                begin
                    if test.Contains('Hello world') then
                    begin
                        if true then begin
                        end;
                        end else begin
                    end; 
                end;

 trigger OnAction();
                var
                    test : Text;
               {
                    if test.Contains('Hello world') then
                    {
                        if true then {                        
                        };
                         else if true {
                        };
                     }; 
               };

Ok, next big point are the variable declarations. I don't think that due to the use of parentheses it is possible to declare variables like in C#.

Personally, I'm a little conflicted. As a developer I say "I want to declare and initialize where I think it is right" but from the point of view of clean code I think it is very good if you say variable must be declared at the beginning of a class or method.

But what I've always wondered. If AL is not designed to handle the full power of development, but also consultants should be able to customize the application, I wonder why there are data types at all. It would be much more sensible to use a quasi DuckTyping under the aspect of simplicity. So the Transcompiler recognizes which data type to use based on the assignment. Why should a consultant have to deal with the paradigm of typing? Well, I know that would be hard work remodeling.

I personally don't mind this fact at the moment.But I wanted to say it once.

The last point is the commas in parameter declarations. Ok, on the one hand, yes, I'm used to other people talking about using a normal comma. And I understand the separation by semicolon in such a way that it is said that they are actually declarations of local variables. But if you consider that a semicolon starts a new statement, it is wrong because the parameters belong to the signature of the method.

Furthermore, it seems to me to be logical with the parameters identical with the call.

Finally, perhaps why I have these wishes. Of course I love C#, but I also have to switch back and forth between many languages and it's just nicer if certain things are simply consistent. And yes, AL will be new, so it has to be measured against existing languages, and I still have a long working life (at least 50 years or more) ahead of me, which means that I may have to work very long with today's syntax decisions.

With everything I bring in I would like to say that I find really cool what you do. :)

[lvanvugt]

I know there has been a discussion when conceiving AL regarding the use of begin end in the code parts. If I recall right it was decided not to change that to { } (curly brackets), to not make the differences with C/AL to big. The curly brackets would solely be used for bordering the various other section (objects, fields, actions, etc.).
I must admit I was in favor of that. Now working with VSCode for some time, I find it somewhat confusing to have both in the same object. And with me various attendees to my workshops. Especially those (and that's what, among others, the modern development experience is aiming at) who do come from environments like Visual Studio. Not in the least the youngster our world is needing.

So my request is also to get rid of the begin .. end construct, in favor of the curly brackets {}

[kine]

My point of view on the {} vs Begin/end:
I understand that C/AL was based on Pascal syntax. Thus the var declaration, ; at the end of command etc. Now it is time to decide - stick on this or create AL as a own, consistent, language? I think the decision was done by using { } in the TXT format of objects in C/Side already. The TXT format is not Pascal syntax and now, AL is trying to stick on the TXT format of the objects (slightly changing it, but I think the AL is more TXT format of C/AL object than C/AL itself). Thus we already left the Pascal syntax.

For me it is same like why = is used to assign value to property, but := to assign value to variable. Why this duplicity? It means, we have TWO assignments operators, and one operator have two meanings based on context (= as compare and as assignment).

Focusing on keeping the change of syntax at minimum is short time decision. It is just because conversion from old system to new one. This is one-time job. Replacing begin/end with { } is simple job. Using it for next X years is much more important. And thus the consistency in the language syntax for me is much more important than consistency with "legacy" system.