|
| 1 | +# AppConfiguration-DotnetProvider Coding Guidelines |
| 2 | + |
| 3 | +This document outlines coding guidelines for the Azure App Configuration .NET Provider repository. Follow these guidelines when generating or modifying code. |
| 4 | + |
| 5 | +## General Guidelines |
| 6 | + |
| 7 | +1. **Exception Handling**: |
| 8 | + * When adding error handling, always catch specific exceptions and avoid catching the base `Exception` class in catch blocks. |
| 9 | + * Throw specific exception types (e.g., `ArgumentNullException`, `FormatException`, custom exceptions) rather than generic `System.Exception`. |
| 10 | + * Include the parameter name when throwing `ArgumentNullException` using `nameof()`. |
| 11 | + |
| 12 | +2. **Variable Declaration**: |
| 13 | + * Never use `var` to declare a variable if the assignment doesn't include the type or the type isn't immediately obvious. |
| 14 | + * Use explicit type names for fields, properties, method parameters, and return types. |
| 15 | + * Use `var` only when the type is obvious from the right-hand side (e.g., `var user = new User();`). |
| 16 | + |
| 17 | +3. **Null Handling**: |
| 18 | + * Validate arguments in public methods and constructors with explicit null checks. |
| 19 | + * Use explicit `if (argument == null) throw new ArgumentNullException(nameof(argument));` checks at the beginning of methods/constructors. |
| 20 | + * Avoid using the null-forgiving operator (`!`) unless absolutely necessary. |
| 21 | + |
| 22 | +4. **Asynchronous Programming**: |
| 23 | + * All async methods should accept a `CancellationToken` as the last parameter. |
| 24 | + * Pass the `cancellationToken` down the call stack to all subsequent asynchronous operations. |
| 25 | + * Use `Task<T>` or `Task` for asynchronous methods. |
| 26 | + |
| 27 | +5. **LINQ and Collections**: |
| 28 | + * Prefer simple, readable LINQ queries. |
| 29 | + * Break down complex LINQ queries into separate statements with intermediate variables. |
| 30 | + * Use collection interfaces (e.g., `IList<T>`, `IReadOnlyList<T>`) in parameter and return types. |
| 31 | + |
| 32 | +6. **Resource Management**: |
| 33 | + * Wrap `IDisposable` instances in `using` statements to ensure proper disposal. |
| 34 | + * Implement `IDisposable` correctly if your class manages disposable objects. |
| 35 | + |
| 36 | +7. **Dependency Injection**: |
| 37 | + * Use constructor injection for dependencies. |
| 38 | + * Store injected dependencies in `private readonly` fields. |
| 39 | + * Validate injected dependencies for null in the constructor. |
| 40 | + |
| 41 | +8. **Naming Conventions**: |
| 42 | + * Use `PascalCase` for classes, interfaces, enums, methods, properties, and constants. |
| 43 | + * Use `camelCase` for local variables and method parameters. |
| 44 | + * Prefix private fields with an underscore (`_`). |
| 45 | + * Define constants for error messages and other string literals. |
| 46 | + |
| 47 | +9. **Comments**: |
| 48 | + * Only add comments when it's not obvious what the code is doing. For example, if a variable name is already fairly descriptive, a comment isn't needed explaining its name. |
| 49 | + * Add summary comments to public classes and members of those classes. |
| 50 | + |
| 51 | +## AppConfiguration-Specific Guidelines |
| 52 | + |
| 53 | +1. **Feature Flag Handling**: |
| 54 | + * Validate feature flag data structure before processing. |
| 55 | + * Handle different feature flag schemas (Microsoft vs .NET) appropriately. |
| 56 | + * Use proper error handling when parsing feature flags with clear error messages. |
| 57 | + |
| 58 | +2. **Configuration Key-Value Processing**: |
| 59 | + * Follow adapter pattern for processing different configuration types. |
| 60 | + * Properly handle key-value pairs with appropriate content type detection. |
| 61 | + * Use `KeyValuePair<string, string>` for configuration values. |
| 62 | + |
| 63 | +3. **Content Type Handling**: |
| 64 | + * Validate content types before processing. |
| 65 | + * Use appropriate content type constants. |
| 66 | + * Check content type using extension methods like `IsFeatureFlag()`. |
| 67 | + |
| 68 | +4. **JSON Parsing**: |
| 69 | + * Use `Utf8JsonReader` for performance-critical JSON parsing. |
| 70 | + * Validate JSON structure and provide clear error messages for malformed input. |
| 71 | + * Handle JSON token types appropriately with proper error handling. |
| 72 | + |
| 73 | +5. **Refresh Mechanisms**: |
| 74 | + * Implement proper configuration refresh patterns. |
| 75 | + * Use sentinel-based refresh mechanisms when appropriate. |
| 76 | + * Handle refresh failures gracefully. |
| 77 | + |
| 78 | +## Performance Considerations |
| 79 | + |
| 80 | +1. **String Handling**: |
| 81 | + * Use `StringBuilder` for concatenating multiple strings. |
| 82 | + * Define string constants for recurring strings. |
| 83 | + * Use string interpolation instead of string concatenation when appropriate. |
| 84 | + |
| 85 | +2. **Collections**: |
| 86 | + * Initialize collections with estimated capacity when possible. |
| 87 | + * Use appropriate collection types for the use case (e.g., `List<T>`, `Dictionary<TKey, TValue>`). |
| 88 | + * Avoid unnecessary collection allocations. |
| 89 | + |
| 90 | +3. **Memory Management**: |
| 91 | + * Use `Span<T>` and `ReadOnlySpan<T>` for high-performance scenarios. |
| 92 | + * Minimize allocations in performance-critical paths. |
| 93 | + * Be mindful of closure allocations in LINQ and lambdas. |
0 commit comments