Coding Standards

We base our guidelines on the Microsoft coding conventions: Microsoft Coding Conventions. There might be minor variations or clarifications, which are outlined here alongside general good practices.

Coding is design. The code reader is the target audience, so readability and understandability are paramount. Prioritize intelligibility, clarity, and transparency over cleverness.

Format

The Kanda SDK packages use CSharpier to format the code. This ensures consistency, and reduces friction when merging branches.

The rules are left to the defaults, except for one:

# csharpierrc.yaml
printWidth: 120

Naming Conventions

• Public fields: PascalCase
• Private fields: _underscoreCamelCase (even if they are [SerializedField])
• Local variables: camelCase
• Type, namespace, property, event, and method names: PascalCase
• Interfaces: IPascalCase (prefixed with a capital “I”)
• Protected or internal fields: PascalCase (visible to derived classes)
• Constants: PascalCase
• Private, static fields: prefixed with s_ (e.g., s_foo)
• Private, [ThreadStatic] fields: prefixed with t_ (e.g., t_bar)

Meaningful Names

Effort in naming variables aids in understanding business logic at a glance. Follow these rules:

Too verbose is better than too short.

// Good
int currentPlayerScore = 0;
 
// Bad
int score = 0;

Purpose is better than data type.

// Good
string playerName = "Alice";
 
// Bad
string str = "Alice";

Self-evident method behavior from name is better than comments.

// Good
void CalculatePlayerScore(int level, int enemiesDefeated)
{
    // Implementation
}
 
// Bad
// This method calculates the player's score based on level and enemies defeated.
void Calculate(int level, int enemiesDefeated)
{
    // Implementation
}

Words are better than single letters.

// Good
float playerHealth = 100.0f;
float playerMaxHealth = 150.0f;
 
// Bad
float h = 100.0f;
float mh = 150.0f;

It is okay to prefix a name with something absurd if it helps clarity, obviousness, self-evidence, or transparency.

Examples:

• Method MethodWithUnsafeConversion_UNSAFE.
• Class UninitializedClass.
• Virtual method ProcessVerifiedData(MyClass data) wrapping ProcessData(MyClass data).

Brackets

Always use brackets for multiline statements.

// Good
if (expression)
{
    // Do stuff
}
else
{
    // Do other stuff
}
// Bad
if (expression)
    // Do stuff
else
    // Do other stuff

Commenting

Names should be self-explanatory and not need comments. When used, comments should explain the reasoning behind solutions:

// We first iterate over the entities because...
// There is a bug in version 1.2.3 where...
// This workaround does (...) and skips (...).

Comments can help group sections or guide the reader’s eyes. Prioritize clean code and avoid checking in commented-out code.

Cyclomatic Complexity

We encourage keeping in mind the measurements of Cyclomatic Complexity.

Use the following score system:

• **<= 4**: Good
• 5 - 7: Okay
• 8 - 10: Bad

For further information on Cyclomatic Complexity, see: Code Complexity and Clean Code.