Method Variable Rules in Dynamics 365 Finance & Operations
Question 39 — Naming, casing, declare-at-use and the English-only development language rule.
Interview Question
Model Answer (Short)
Method variable names must begin with a lowercase letter and use camelCase, and
they must not contain underscores. Variables should be declared at the point of use
rather than all bunched at the top of the method — this keeps a variable close to where it's needed and improves
readability. One important exception exists for parameters, which by convention begin with a
leading underscore (e.g. _salesId). Finally, all development must be in English — new
object and child-component names, variable and parameter names, and both header and inline comments — because it is
a Microsoft best practice that keeps code readable for every developer.
Detailed Explanation
Variable naming & casing
- Method variable names must begin with lowercase.
- Use camelCase for the remaining words.
- Do not use underscores in method variable names.
- By convention, parameters begin with a leading underscore (e.g.
_custAccount).
Declare at the point of use
- Declare a variable where it is first used, not all at the top of the method.
- This keeps the declaration close to its usage and improves readability.
English-only development
- All development must be in English (a Microsoft best practice).
- Applies to new object and child-component names.
- Applies to variable and parameter names.
- Applies to header and inline comments.
Prerequisites (Rule 5)
- Visual Studio with the Dynamics 365 developer tools.
- A custom model / package for your objects.
- The project's naming conventions agreed and understood.
Code Example — Correct variable & parameter naming
// Parameters start with _ | variables are camelCase (no underscores)
public Amount calcLineTotal(SalesLine _salesLine, Percent _discountPct)
{
Amount grossAmount = _salesLine.SalesQty * _salesLine.SalesPrice;
Amount netAmount = grossAmount * (1 - _discountPct / 100);
return netAmount;
}Declare at point of use
public void processCustomers()
{
// GOOD: declared right where first used
CustTable custTable;
while select custTable
{
Amount balance = this.getBalance(custTable.AccountNum); // declared at use
info(strFmt("%1 : %2", custTable.AccountNum, balance));
}
}Avoid: underscores & non-English names
// BAD: underscore in a variable + non-English identifier
int total_amount = 0; // underscore not allowed in variables
int montantTotal = 0; // not English
// GOOD
int totalAmount = 0; // camelCase, EnglishNaming Quick Reference
| Item | Rule | Example |
|---|---|---|
| Method variable | lowercase start, camelCase, no underscore | netAmount |
| Parameter | Leading underscore | _salesLine |
| Declaration | At the point of use | Amount balance = ... |
| Language | English only | totalAmount (not montantTotal) |
Points the interviewer wants to hear
- Method variables: lowercase start, camelCase, no underscores.
- Parameters use a leading underscore by convention.
- Declare variables at the point of use, not all at the top.
- All development is in English — names, variables, params and comments.
- English-only is a Microsoft best practice for readability.
Likely Follow-up Questions
- Why declare variables at the point of use rather than at the top?
- How do you distinguish a parameter from a local variable by name?
- Why must all development be in English?
- Are underscores allowed anywhere in variable naming?
Key Takeaway
Name method variables in camelCase with a lowercase start and no underscores, reserve the leading underscore for parameters, declare variables at the point of use, and keep all development in English for universal readability.