Added tags & categories + cleanup

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/_index.md

@@ -1,6 +1,8 @@
 +++
 title = "Readability"
 weight = 980
+tags = ["C/AL","Readability"]
+categories = ["Best Practice"]
 +++
 ## C/AL Coding Guidelines
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/begin-as-an-afterword/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/begin-end/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/binary-operator-line-start/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/blank-lines/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/case-actions/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/colon-usage-in-case/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/comments-curly-brackets/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/comments-spacing/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/end-else-pair/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/indentation/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/keyword-pairs-indentation/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/line-start-keywords/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/lonely-repeat/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/named-invocations/index.md

@@ -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
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/nested-withs/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/one-statement-per-line/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/separate-if-and-else/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/spacing-binary-operators/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/spacing-brackets-and/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/spacing-unary-operators/index.md

@@ -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).
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/suggested-abbreviations/index.md

@@ -1,6 +1,8 @@
 +++
 title = "Suggested Abbreviations"
 weight = 1170
+tags = ["C/AL","Readability"]
+categories = ["Best Practice"]
 +++
 ### Suggested Abbreviations
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/temporary-variable-naming/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/textconst-suffixes/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unary-operator-line-end/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unnecessary-compound-parenthesis/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unnecessary-else/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unnecessary-function-parenthesis/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unnecessary-separators/index.md

@@ -1,6 +1,8 @@
 +++
 title = "Unnecessary Separators"
 weight = 1290
+tags = ["C/AL","Readability"]
+categories = ["Best Practice"]
 +++
 There should be no unnecessary separators.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/unnecessary-truefalse/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/variable-already-scoped/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/variable-naming/index.md

@@ -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.
 

content/docs/NAVPatterns/3-cal-coding-guidelines/readability/variables-declarations-order/index.md

@@ -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.