4266421a4c
* Refactor bookmark management and add new features Streamlined bookmark handling by eliminating temporary storage in `ActivityExecutionContext` and directly managing bookmarks in `WorkflowExecutionContext`. Documented architectural decisions using ADRs. * Regenerate EF Core migrations * Refactor fault tracking to use AggregatedFaultCount property. Replaces FaultCount with AggregatedFaultCount across the codebase to improve clarity and consistency in fault tracking. Updates related methods, properties, and data mappings to align with the new terminology. Fixes initialization issue with nullable inputs in Fault class. * Add migration to track fault counts in runtime (V3.5) This migration adds a new column, "AggregatedFaultCount," to the "ActivityExecutionRecords" table. The column is an integer, non-nullable, with a default value of 0, and enables tracking aggregated fault occurrences. The migration also includes a rollback to remove this column if needed. * Fix typo in ADR 0004 regarding bookmark management convention Corrected a spelling mistake in the ADR documentation by changing "determins" to "determines." This ensures clarity and maintains the professionalism of the document. No functional changes were made. * Refine fault propagation logic for child-parent activities Replace automatic fault transitions of parent activities with an aggregate fault count for descendant activities. This avoids premature state changes while still indicating child activity faults, improving workflow resilience and accuracy. * Remove signal-driven fault propagation ADR and renumber bookmarks ADR The ADR for signal-driven fault propagation was deleted, and the direct bookmark management ADR was renamed and renumbered accordingly. Related references in the table of contents, graph, and solution file were updated to reflect these changes. * Refactor DeleteBookmarks to improve readability. Reformatted the BookmarkFilter initialization for better clarity and maintainability. This change ensures the code is more aligned with modern C# conventions and improves overall readability. No behavior or functionality has been altered. * Refactor naming for "AggregatedFaultCount" to "AggregateFaultCount" Standardized the terminology across the codebase and migrations by renaming all references of "AggregatedFaultCount" to "AggregateFaultCount" for improved consistency and readability. Updated relevant logic, models, migrations, and database contexts accordingly.
2.3 KiB
2.3 KiB
Pull Request Quality Standard Checklist
Coding Standards
- Follows Microsoft's coding guidelines, with the following exceptions:
- Use of
var: Usevarfor variable declarations consistently. See rationale below.
- Use of
Documentation
- XML comments provided for all public members.
- Inline comments explain complex logic.
Testing
- Unit tests cover critical functions.
- Integration tests for major workflows.
- High code coverage.
Code Review
- Peer review completed.
- Passes automated code analysis.
Continuous Integration
- CI checks pass (builds, tests, style checks).
Performance and Security
- Performance is optimized where necessary.
- Security best practices followed.
Dependencies and Compatibility
- Dependencies are managed and up to date.
- No breaking changes without documentation.
Rationale for Using var
We have chosen to use var consistently in our codebase for the following reasons:
- Cleaner Code: Using
varreduces visual clutter and makes the code cleaner and more readable. It helps avoid redundant type information, especially when the type is already apparent from the right-hand side of the declaration. - Modern IDEs: Tools like Visual Studio and other modern IDEs provide features such as hover or tool tips that easily display variable types, alleviating concerns about readability. This makes it unnecessary to explicitly specify the type, as it can be easily inferred by the developer.
- Consistency and Maintenance: Consistent use of
varacross the codebase promotes uniformity and reduces the mental load on developers. It simplifies refactoring because changes to the type do not require updating the variable declaration. - Focus on Logic: By using
var, developers can focus on the logic and functionality of the code rather than getting bogged down by type details. This is particularly beneficial in complex expressions and LINQ queries where the type is often verbose and less important than the expression itself.
These points align with the insights from Chris Schaller's blog post "To var or not to var," which emphasizes that using var can lead to more maintainable and readable code in the context of modern development environments.