Merge branch 'main' into InstallHugoOnWindows11
This commit is contained in:
Henrik Helgesen
GitHub
commit
1486266329
208 changed files with 398 additions and 244 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 279 KiB |
|
|
@ -1,2 +1,7 @@
|
|||
.td-page-meta--child { display: none !important; }
|
||||
.td-page-meta--project-issue { display: none !important; }
|
||||
.td-page-meta--project-issue { display: none !important; }
|
||||
|
||||
.td-content pre code {
|
||||
font-family: Consolas, "Courier New", monospace;
|
||||
size: 115%;
|
||||
}
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
+++
|
||||
chapter = true
|
||||
pre = "<b><i class='fas fa-clone'></i> </b>"
|
||||
title = "Discussions"
|
||||
weight = 200
|
||||
+++
|
||||
|
||||
# [Discussions](https://github.com/microsoft/alguidelines/discussions)
|
||||
|
||||
We enabled the "Discussions" forum on the github-page of our repository for you to discuss anything "Design Pattern" or "Best Practices" related.
|
||||
|
||||
You can find the discussions here: https://github.com/microsoft/alguidelines/discussions.
|
||||
|
||||
Feel free to browse through them, find certain topics and/or participate in the discussions!
|
||||
|
||||
## Create your own discussion
|
||||
|
||||
You are obviously also free to start a new discussion. You can simply do that by using the "New Discussion" button on the top right.
|
||||
|
||||
Or use this link: https://github.com/microsoft/alguidelines/discussions/new?category=bc-patterns
|
||||
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: "DeleteAll"
|
||||
tags: ["Performance"]
|
||||
tags: ["AL","Performance"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
<_Created by waldo, Described by waldo_\>
|
||||
_Created by waldo, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
|
|
@ -25,11 +25,3 @@ Therefore it's good practice to always check if the table is empty when performi
|
|||
if not EmptyTableWLD.IsEmpty() then
|
||||
EmptyTableWLD.DeleteAll(true);
|
||||
```
|
||||
|
||||
## Discussions
|
||||
|
||||
You can discuss the guideline [here](https://github.com/microsoft/alguidelines/discussions/107)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Subscriber Codeunits"
|
||||
tags: ["Performance"]
|
||||
tags: ["AL","Performance"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -18,15 +18,18 @@ In general, subscribers have to be put in codeunits. There are a few performanc
|
|||
Let's discuss all points
|
||||
|
||||
## Keep the codeunit as small as possible
|
||||
|
||||
Every time a subscriber gets called, a new instance of the codeunit is being loaded in memory, which takes memory and processing power. The smaller the codeunit, the less memory, and the faster it is.
|
||||
|
||||
Therefore, it's suggested to split the subscribers by functionality and avoid putting business logic in the actual codeunit. Tip: put all business logic in an "[Method Codeunit](https://alguidelines.dev/bcpatterns/generic-method-pattern/)".
|
||||
|
||||
Examples:
|
||||
|
||||
- if you app does things on Sales and Purchase, create a Sales-subs codeunit, and a Purchase-subs.
|
||||
- if you have multiple functionalities in your app (let's call'm modules), create a subs-codeunit per module, and only add the subscribers in there that are necessary for that module.
|
||||
|
||||
### Bad code
|
||||
|
||||
```AL
|
||||
codeunit 2037325 "Setup Subs"
|
||||
{
|
||||
|
|
@ -73,6 +76,7 @@ codeunit 2037325 "Setup Subs"
|
|||
end;
|
||||
}
|
||||
```
|
||||
|
||||
### Good code
|
||||
|
||||
Split into 2 codeunits, and move the business logic out.
|
||||
|
|
@ -112,6 +116,7 @@ codeunit 2037324 "RHE Setup Subs"
|
|||
To avoid the extra "loading of the content" while a subscriber is being executed, use Single Instance codeunit for subscribers. Do take into account, of course, that it would share the state across the entire session.
|
||||
|
||||
### Bad code
|
||||
|
||||
```AL
|
||||
codeunit 2037324 "RHE Setup Subs"
|
||||
{
|
||||
|
|
@ -124,7 +129,9 @@ codeunit 2037324 "RHE Setup Subs"
|
|||
end;
|
||||
}
|
||||
```
|
||||
|
||||
### Good code
|
||||
|
||||
```AL
|
||||
codeunit 2037324 "RHE Setup Subs"
|
||||
{
|
||||
|
|
@ -145,6 +152,7 @@ codeunit 2037324 "RHE Setup Subs"
|
|||
If possible, only execute the subscriber when really necessary by using Manual Binding.
|
||||
|
||||
### Bad code
|
||||
|
||||
```AL
|
||||
//subscriber - code should actually only run when Color=Red.
|
||||
[EventSubscriber(ObjectType::Table, Database::"Just Some Table WLD", 'OnAfterValidateEvent', 'Message 2', false, false)]
|
||||
|
|
@ -162,7 +170,9 @@ If possible, only execute the subscriber when really necessary by using Manual B
|
|||
JustSomeTable.Validate("Message 2", format(Random(1000)));
|
||||
until JustSomeTable.Next() < 1;
|
||||
```
|
||||
|
||||
### Good code
|
||||
|
||||
```AL
|
||||
if JustSomeTable.FindSet() then
|
||||
repeat
|
||||
|
|
@ -177,21 +187,15 @@ If possible, only execute the subscriber when really necessary by using Manual B
|
|||
```
|
||||
|
||||
## Avoid OnInsert/OnModify/OnDelete
|
||||
|
||||
The reason for this is, that it breaks the batch-calls:
|
||||
|
||||
- Any "OnInsert" subscriber breaks the bulk inserts, simply because it needs to perform an operation after every record that was inserted
|
||||
- Any "OnModify" subscriber slows down the "ModifyAll", simply because it needs to perform an operation after every record that was modified. I fact: 1 SQL call is turned into a loop of SQL calls.
|
||||
- Any "OnDelete" subscriber slows down the "DeleteAll", simply because it needs to perform an operation after every record that was deleted. I fact: 1 SQL call is turned into a loop of SQL calls.
|
||||
|
||||
Avoid subscribers to these events.
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/92)
|
||||
|
||||
You can discuss this guidelines [here](https://github.com/microsoft/alguidelines/discussions/92).
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
||||
## References
|
||||
|
||||
The [Generic Method Pattern](https://alguidelines.dev/bcpatterns/generic-method-pattern/)
|
||||
|
|
@ -5,8 +5,6 @@ description: >
|
|||
AL Code Best Practices
|
||||
---
|
||||
|
||||
# Business Central Best Practices
|
||||
|
||||
This section will be cover things that aren't as simple as Design Patterns, but will help make sure your development is:
|
||||
|
||||
- high-performance
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "begin as an afterword"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -27,8 +27,3 @@ When `begin` follows `then`, `else`, `do`, it should be on the same line, preced
|
|||
end;
|
||||
```
|
||||
|
||||
## Discussion
|
||||
|
||||
Discuss this Best Practice [here](https://github.com/microsoft/alguidelines/discussions/123)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Begin-End - Compound Only"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -53,8 +53,3 @@ end else
|
|||
(not X)
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=begin+end+compound+only+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Binary Operator to Start Line"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -25,9 +25,3 @@ Quantity
|
|||
Quantity -
|
||||
"Quantity Shipped"
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=binary+operator+to+start+line+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "CASE Action on next line"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ _Created by Microsoft, Described by waldo_
|
|||
|
||||
## Description
|
||||
|
||||
A CASE action should start on a line after the possibility.
|
||||
A CASE action should start on a line after the possibility.
|
||||
|
||||
## Bad code
|
||||
|
||||
|
|
@ -29,9 +29,3 @@ A CASE action should start on a line after the possibility.
|
|||
Letter2 := '11';
|
||||
end;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=case+action+on+next+line+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Comment Spacing"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
Always start comments with // followed by one space character.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -14,16 +15,9 @@ Always start comments with // followed by one space character.
|
|||
```al
|
||||
RowNo += 1000; //Move way below the budget
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
RowNo += 1000; // Move way below the budget
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=comment+spacing+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "end else pair"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -33,9 +33,3 @@ The `end else` pair should always appear on the same line.
|
|||
...
|
||||
end;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=end+else/pair+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Keyword Pairs - Indentation"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
The `if..then` pair, `while..do` pair, and `for..do` pair must appear on the same line or the same level of indentation. If possible, you can align the lines it is even much more readable.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -23,9 +24,3 @@ The `if..then` pair, `while..do` pair, and `for..do` pair must appear on the sam
|
|||
(a = b)
|
||||
then
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=keyword+pair+indentation+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,11 +1,12 @@
|
|||
---
|
||||
title: "Line Start Keywords"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
<_Created by Microsoft, Described by waldo_\>
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
The `end`, `if`, `repeat`, `for`, `while`, `else` and `case` statement should always start a line.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -28,10 +29,3 @@ The `end`, `if`, `repeat`, `for`, `while`, `else` and `case` statement should al
|
|||
if IsSalesCycleCode then
|
||||
ValidatSalesCycleCode();
|
||||
```
|
||||
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=line+start+keyword+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Lonely Repeat"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
The `repeat` statement should always be alone on a line.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -14,16 +15,10 @@ The `repeat` statement should always be alone on a line.
|
|||
```al
|
||||
if ReservEntry.FindSet() then repeat
|
||||
```
|
||||
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
if ReservEntry.FindSet() then
|
||||
repeat
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=lonely+repeat+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Named Invocations"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
When calling an object statically use the Object Name, not the Object Id.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -20,9 +21,3 @@ When calling an object statically use the Object Name, not the Object Id.
|
|||
```al
|
||||
Page.RunModal(Page::"Posted Sales Shipment Lines", SalesShptLine);
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=named+invocations+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,34 +1,33 @@
|
|||
---
|
||||
title: "One Statement per Line"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
A line of code should not have more than one statement.
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
if OppEntry.Find('-') then exit;
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
if OppEntry.Find('-') then
|
||||
exit;
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
TotalCost += Cost; TotalAmt += Amt;
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
|
|
@ -36,9 +35,3 @@ A line of code should not have more than one statement.
|
|||
TotalCost += Cost;
|
||||
TotalAmt += Amt;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=one+statement+per+line+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Seperate if and else"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
`if` and `else` statements should be on separate lines.
|
||||
|
||||
## Bad code
|
||||
|
|
@ -26,10 +27,3 @@ _Created by Microsoft, Described by waldo_
|
|||
...
|
||||
end;
|
||||
```
|
||||
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=separate+if+and+else+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,46 +1,47 @@
|
|||
---
|
||||
title: "Spacing Binary Operators"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
There must be exactly one space character on each side of a binary operator such as = + - AND OR =. The parameter comma operator however, should have a space after the comma.
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
"Line Discount %" := "Line Discount Amount"/"Line Value"*100;
|
||||
```
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
"Line Discount %" := "Line Discount Amount" / "Line Value" * 100;
|
||||
```
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
StartDate := CalcDate('<+'+Format(Days+i)+'D\>',StartDate);
|
||||
```
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
StartDate := CalcDate('<+' + Format(Days + i) + 'D\>', StartDate);
|
||||
```
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
StartDate:=0D; // Initialize
|
||||
```
|
||||
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
StartDate := 0D; // Initialize
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Suggested Abbreviations"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -359,9 +359,3 @@ If there is no other choice, then use the suggestions below.
|
|||
| % | Pct |
|
||||
| 3-tier | Three-Tier |
|
||||
| Outlook Synch | Osynch |
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=abbreviations+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Unnecessary else"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -32,9 +32,3 @@ _Created by Microsoft, Described by waldo_
|
|||
Error(BinCodeChangeNotAllowedErr, ...);
|
||||
end;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=unnecessary+else+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Unnecessary true/false"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -13,29 +13,22 @@ Do not use `true` or `false` keywords unnecessarily if the expression is already
|
|||
|
||||
```al
|
||||
if IsPositive() = true then
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
if IsPositive() then
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
if Complete <> true then
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
if not Complete then
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=unnecessary+true+false+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Variable Naming"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
Variables that refer to a AL object must contain the objects name, abbreviated where necessary.
|
||||
|
||||
A variable must begin with a capital letter.
|
||||
|
|
@ -20,29 +21,33 @@ If a variable is a compound of two or more words or abbreviations, each word or
|
|||
```al
|
||||
WIPBuffer: Record "Job WIP Buffer"
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
JobWIPBuffer: Record "Job WIP Buffer"
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
Postline: Codeunit "Gen. Jnl.-Post Line";
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
GenJnlPostLine: Codeunit "Gen. Jnl.-Post Line";
|
||||
```
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
"Amount (LCY)": Decimal;
|
||||
```
|
||||
|
||||
## Good code
|
||||
|
||||
```al
|
||||
AmountLCY: Decimal;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=one+variable+naming+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: "Variables Declarations Order"
|
||||
tags: ["Readability"]
|
||||
tags: ["AL","Readability"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
_Created by Microsoft, Described by waldo_
|
||||
|
||||
## Description
|
||||
|
||||
Variables declarations should be ordered by type. In general, object and complex variable types are listed first followed by simple variables. The order should be:
|
||||
|
||||
- Record
|
||||
|
|
@ -25,7 +26,6 @@ Variables declarations should be ordered by type. In general, object and complex
|
|||
|
||||
(Ref: [Microsoft Docs](https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/analyzers/codecop-aa0021))
|
||||
|
||||
|
||||
## Bad code
|
||||
|
||||
```al
|
||||
|
|
@ -39,9 +39,3 @@ Variables declarations should be ordered by type. In general, object and complex
|
|||
Vendor: Record Vendor;
|
||||
StartingDateFilter: Text;
|
||||
```
|
||||
|
||||
## [Discussions](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices?discussions_q=one+variables+declarations+order+category%3A%22BC+Best+Practices%22)
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
If you don't find the discussion of this guideline, please feel free to create a new one with the same title as this article.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Title Here"
|
||||
tags: []
|
||||
tags: ["AL"]
|
||||
categories: ["Best Practice"]
|
||||
---
|
||||
|
||||
|
|
@ -29,11 +29,3 @@ PutCodeblocksHere()
|
|||
```al
|
||||
PutCodeblocksHere()
|
||||
```
|
||||
|
||||
## Discussions
|
||||
|
||||
Please discuss this guideline <!--[here](https://github.com/microsoft/alguidelines/discussions/42) Fix the link -->
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-best-practices).
|
||||
|
||||
<!-- Create a discussions-page of your pattern, and add the sentence "You can discuss this pattern [here](https://github.com/microsoft/alguidelines/discussions/42)" with the right link to that discussions-page. -->
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: "Pattern Name"
|
||||
tags: []
|
||||
categories: ["Pattern"]
|
||||
---
|
||||
+++
|
||||
title = "Pattern Name"
|
||||
tags = ["AL"]
|
||||
categories = ["Pattern"]
|
||||
+++
|
||||
|
||||
<!-- This is a guideline, some parts are optional (if there's no content, remove the whole paragraph). -->
|
||||
|
||||
|
|
@ -44,11 +44,3 @@ Usually, there are occasions where NOT to implement the pattern. List the disad
|
|||
## List of references
|
||||
|
||||
Youtube-link? BaseApp? Tweet? ...
|
||||
|
||||
## Discussions
|
||||
|
||||
Please discuss this guideline <!--[here](https://github.com/microsoft/alguidelines/discussions/42) Fix the link -->
|
||||
|
||||
You can find discussions on all "Best Practices" [here](https://github.com/microsoft/alguidelines/discussions/categories/bc-patterns).
|
||||
|
||||
<!-- Create a discussions-page of your pattern, and add the sentence "You can discuss this pattern [here](https://github.com/microsoft/alguidelines/discussions/42)" with the right link to that discussions-page. -->
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
chapter = true
|
||||
title = "2. Anti-Patterns"
|
||||
weight = 130
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
Some of the software development practices, had **not** stood the test of time. Despite that, some are still being used today by developers everywhere.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "Nav Upgrade"
|
||||
weight = 840
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
## Anti-Patterns in NAV Upgrade
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "Reusable Bugs"
|
||||
weight = 1020
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
_By Bogdana Botez, Andreas Moth, Eric Wauters (waldo), Elly Nkya, Nikola Kukrika_
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
chapter = true
|
||||
title = "3. CAL Coding Guidelines"
|
||||
weight = 150
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
We've decided to publish our current C/AL coding guidelines. They are actual, as per January 2015 when this is published (but might fall out of sync as time goes by).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Design"
|
||||
weight = 490
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
## C/AL Coding Guidelines
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "By Reference Parameters"
|
||||
weight = 280
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not declare parameters by reference if their values are not intended to be changed.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Class Coupling"
|
||||
weight = 320
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not write functions that have high class coupling. This makes the code hard to maintain.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Cyclomatic Complexity"
|
||||
weight = 460
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not write functions that have high cyclomatic complexity. This makes the code hard to maintain.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
+++
|
||||
title = "Encapsulate Local Functionality"
|
||||
weight = 530
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Any function used local must be defined as local.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "FINDSET FINDFIRST FINDLAST"
|
||||
weight = 600
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
FINDSET, FIND('+') or FIND('-') should only be used when NEXT is used and vice versa.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Initialized Variables"
|
||||
weight = 660
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Variables should always be set to a specific value, before they are used.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Maintainability Index"
|
||||
weight = 770
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
[Maintainability Index][anchor0]: Do not write functions that have a very low maintainability index. This makes the code hard to maintain.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Parameter Placeholders"
|
||||
weight = 920
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The number of parameters passed to a string must match the placeholders.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Static Object Invocation"
|
||||
weight = 1160
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Call objects statically whenever possible. It reduces extra noise and removes extra variables. Downside: changing the name of the object which is called statically will need a code update.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unreachable Code"
|
||||
weight = 1310
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not write code that will never be hit.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unused Initialized Variables"
|
||||
weight = 1320
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The value assigned to a variable must be used. Else the variable is not necessary.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unused Variables"
|
||||
weight = 1330
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not declare variables that are unused.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Variable Capacity Mismatch"
|
||||
weight = 1410
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not assign a value to a variable whose capacity is smaller.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "WITH Scope Name Collision"
|
||||
weight = 1450
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not use the WITH scope when it has a variable whose name is the same as a local variable. This can lead to wrong code assumptions.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Internally used DotNet Types"
|
||||
weight = 690
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
_(Dynamics NAV 2015)_
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Internationalization"
|
||||
weight = 700
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
## C/AL Coding Guidelines
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Using Calcdate"
|
||||
weight = 1370
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
CALCDATE should only be used with DateFormula variables. Alternatively the string should be enclosed using the <> symbols.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Localizability"
|
||||
weight = 750
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
## C/AL Coding Guidelines
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "CaptionML on System Pages"
|
||||
weight = 300
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
CaptionML should always be specified on a page field for a system table. By default, system tables do not have captions, so if you need to use them in the UI then captions need to be added.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "FIELDCAPTION and TABLECAPTION"
|
||||
weight = 580
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
For user messages, errors etc., use FIELDCAPTION not FIELDNAME and TABLECAPTION not TABLENAME.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Global Text Constants"
|
||||
weight = 610
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Declare Text Constant as global variables.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Use Text Constants"
|
||||
weight = 1360
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Pass user messages using Text Constants. It makes translation easy.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Using OptionCaptionML"
|
||||
weight = 1380
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The OptionCaptionML should be filled in for sourceexpression using option data types.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Readability"
|
||||
weight = 980
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
## C/AL Coding Guidelines
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Begin as an 'After Word'"
|
||||
weight = 230
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
When BEGIN follows THEN, ELSE, DO, it should be on the same line, preceded by one space character.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Begin-End - Compound Only"
|
||||
weight = 240
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Only use BEGIN..END to enclose compound statements.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Binary Operator to Start Line"
|
||||
weight = 250
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not start a line with a binary operator.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Blank Lines"
|
||||
weight = 260
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not use blank lines at the beginning or end of any functions, after BEGIN, before END, or inside multiline expressions.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "CASE Action"
|
||||
weight = 310
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
A CASE action should start on a line after the possibility.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Colon usage in CASE"
|
||||
weight = 340
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The last possibility on a CASE statement must be immediately followed by a colon.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Comments inside Curly Brackets"
|
||||
weight = 350
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Never use curly bracket comments. During development, the "Block comment" functionality can be used instead. However, in production code, block comments are not recommended.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Comment Spacing"
|
||||
weight = 360
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Always start comments with // followed by one space character.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "END ELSE Pair"
|
||||
weight = 540
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The END ELSE pair should always appear on the same line.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Indentation"
|
||||
weight = 650
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
In general, use an indentation of two space characters. Logical expressions in the IF, WHILE, and UNTIL parts are indented at least 3, 6, and 6 spaces respectively.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Keyword Pairs - Indentation"
|
||||
weight = 730
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The IF..THEN pair, WHILE..DO pair, and FOR..DO pair must appear on the same line or the same level of indentation.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Line Start Keywords"
|
||||
weight = 740
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The END, IF, REPEAT, FOR, WHILE, ELSE and CASE statement should always start a line.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Lonely Repeat"
|
||||
weight = 760
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The REPEAT statement should always be alone on a line.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Named Invocations"
|
||||
weight = 830
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
When calling an object statically use the name, not the number
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Nested WITHs"
|
||||
weight = 850
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not nest WITHs that reference different types of objects.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "One Statement Per Line"
|
||||
weight = 910
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
A line of code should not have more than one statement.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Separate IF and ELSE"
|
||||
weight = 1050
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
IF and ELSE statements should be on separate lines.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Spacing Binary Operators"
|
||||
weight = 1120
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
There must be exactly one space character on each side of a binary operator such as = + - AND OR =. The parameter comma operator however, should have no spaces.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Spacing Brackets and ::"
|
||||
weight = 1130
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
There must be no spaces characters before and after [] dimension brackets symbols or :: option symbols.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Spacing Unary Operators"
|
||||
weight = 1140
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
There must be no space between a unary operator and its argument (except for the NOT keyword).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Suggested Abbreviations"
|
||||
weight = 1170
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
### Suggested Abbreviations
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Temporary Variable Naming"
|
||||
weight = 1200
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
The name of a temporary variable must be prefixed with the word Temp and not otherwise.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "TextConst Suffixes"
|
||||
weight = 1210
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
TextConst variable names should have a suffix (an approved three-letter suffix: Msg, Tok, Err, Qst, Lbl, Txt) describing usage.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unary Operator Line End"
|
||||
weight = 1250
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not end a line with unary operator.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unnecessary Compound Parenthesis"
|
||||
weight = 1260
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Use parenthesis only to enclose compound expressions inside compound expressions.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unnecessary ELSE"
|
||||
weight = 1270
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
ELSE should not be used when the last action in the THEN part is an EXIT, BREAK, SKIP, QUIT, ERROR.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unnecessary Function Parenthesis"
|
||||
weight = 1280
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not use parenthesis in a function call if the function does not have any parameters.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unnecessary Separators"
|
||||
weight = 1290
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
There should be no unnecessary separators.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Unnecessary TRUE/FALSE"
|
||||
weight = 1300
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not use TRUE or FALSE keywords unnecessarily if the expression is already an logical expression.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Variable Already Scoped"
|
||||
weight = 1400
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Do not use scope ''.'' qualifier unnecessarily when a variable is already implicitly or explicitly scoped. It keeps the code simpler.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Variable Naming"
|
||||
weight = 1420
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Variables that refer to a C/AL object must contain the objects name, abbreviated where necessary.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Variables Declarations Order"
|
||||
weight = 1430
|
||||
tags = ["C/AL","Readability"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Variables declarations should be ordered by type. In general, object and complex variable types are listed first followed by simple variables. The order should be the same as the object list in the object designer for C/AL objects. Afterwards come the complex variables like RecordRef, .NET, FieldRef etc. At the end come all the simple data types in no particular order.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "UX"
|
||||
weight = 1390
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
## C/AL Coding Guidelines
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Actions - Images"
|
||||
weight = 200
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
All actions must have an image assigned to them.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "CONFIRM"
|
||||
weight = 380
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Always end CONFIRM with a question mark.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "FIELDERROR"
|
||||
weight = 590
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Never use FIELDERROR with a period as it is automatically inserted.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "MESSAGE and ERROR"
|
||||
weight = 790
|
||||
tags = ["C/AL"]
|
||||
categories = ["Best Practice"]
|
||||
+++
|
||||
Always end MESSAGE or ERROR with a period.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
chapter = true
|
||||
title = "(OLD) Get Involved"
|
||||
weight = 170
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
|
||||
**Reminder, this is an ARCHIVE of the Patterns site, this information is not current.**
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "Code of Conduct"
|
||||
weight = 330
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
Find below the rules to be used when disseminating or relating to the NAV Design Patterns.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "Patterns Authors"
|
||||
weight = 930
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
This is the list of people that have been part of the NAV Design Patterns team. If you would like to join the project follow the instructions provided on [Be a NAV Pattern Author][anchor0] page.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "Template for writing Nav Design Patterns"
|
||||
weight = 1180
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
This is a guideline, some parts are optional (if there's no content, remove the whole paragraph).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
+++
|
||||
title = "NAV Patterns Archive"
|
||||
weight = 20
|
||||
tags = ["C/AL"]
|
||||
+++
|
||||
|
||||
## About the archive
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: "Patterns"
|
||||
title: "1. Patterns"
|
||||
weight: 110
|
||||
tags: ["NAV", "C/AL"]
|
||||
categories: ["Archived Pattern"]
|
||||
tags: ["C/AL"]
|
||||
categories: ["Pattern"]
|
||||
description: >
|
||||
Patterns described to be used with Microsoft Dynamics NAV
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Activity Logs"
|
||||
weight = 210
|
||||
tags = ["C/AL"]
|
||||
categories = ["Pattern"]
|
||||
+++
|
||||
_Originally by Ciprian Iordache at Microsoft Development Center Copenhagen_
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
+++
|
||||
title = "Argument Table"
|
||||
weight = 220
|
||||
tags = ["C/AL"]
|
||||
categories = ["Pattern"]
|
||||
+++
|
||||
_Originally By Nikola Kukrika and waldo_
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue