Average X++ Code vs Microsoft-Standard Code in D365 F&O
In the world of D365 Finance and Operations development, the difference between a working solution and a scalable, maintainable one often lies in the quality of your code.
In this article, I’ll highlight a real-world example: controlling the “New” button on the LedgerJournalTable form based on user roles. We’ll compare an average implementation with one that follows Microsoft’s clean coding standards—emphasizing structure, reusability, and readability.
Whether you're new to X++ or looking to level up your development approach, this comparison will help you write cleaner, future-proof code.
Average X++ Code:
Microsoft-Standard Code:
Key Differences: Average Code vs. Microsoft-Standard Code
Here’s a breakdown of why the Microsoft-standard code is better, structured as clear and actionable points:
Separation of Concerns:
Average Code: All logic is written inside the init() method.
Standard Code: Business logic is abstracted into private methods (setCreatePermissionBasedOnRole, userHasSecurityRole).
Why It Matters: Enhances readability, testability, and long-term maintainability.
Hardcoding:
Average Code: The role name is hardcoded directly within the logic.
Standard Code: The role name is defined once using a constant (const str RoleName).
Why It Matters: Centralizes role management and makes future updates easier.
Code Reusability:
Average Code: Role-checking query is written inline and can't be reused elsewhere.
Standard Code: Logic is separated into reusable methods that can be called across different contexts.
Why It Matters: Encourages clean architecture and reduces code duplication.
Readability:
Average Code: Logic is mixed and not easy to follow at a glance.
Standard Code: Method names describe their purpose clearly; each method has a single responsibility.
Why It Matters: Makes the code easier to understand for collaborators or future maintainers.
Encapsulation:
Average Code: No encapsulation; everything is exposed and handled in one place.
Standard Code: Uses private methods to isolate and encapsulate internal logic.
Why It Matters: Protects implementation details and enforces better coding discipline.
Inline Cursor Use:
Average Code: Includes an unnecessary cursor assignment (LedgerJournalTable_DS.Cursor();) which is not used.
Standard Code: No unused cursors or redundant variables are declared.
Why It Matters: Keeps code clean, minimal, and free of confusion.
Maintainability:
Average Code: Changes or extensions (like checking more roles) require editing complex inline logic.
Standard Code: Easy to extend or adjust by modifying isolated helper methods.
Why It Matters: Future changes become safer, faster, and less error-prone.
Note: Of course, this isn’t a perfect implementation—I’m not Microsoft 😄. The goal here is to follow clean, maintainable practices as closely as possible. If you have any suggestions, improvements, or alternative approaches, feel free to share them in the comments.
I’d love to learn from your input!
Babar Salman
Lead Digital Engineer at Sonata Software
1moGreat