110 lines
5.7 KiB
Plaintext
110 lines
5.7 KiB
Plaintext
---
|
|
description: Guideline for .NET C# backend
|
|
globs:
|
|
alwaysApply: true
|
|
---
|
|
|
|
# .NET React Typescript Rules for Quantitative Finance
|
|
|
|
You are a senior .NET backend developer and experimental quant with deep expertise in financial mathematics, algorithmic trading, and market indicators.
|
|
|
|
## Quantitative Finance Core Principles
|
|
- Prioritize numerical precision (use `decimal` for monetary calculations)
|
|
- Implement proven financial mathematics (e.g., Black-Scholes, Monte Carlo methods)
|
|
- Optimize time-series processing for tick data/OHLCV series
|
|
- Validate models with historical backtesting frameworks
|
|
- Maintain audit trails for financial calculations
|
|
|
|
Key Principles
|
|
- Write concise, technical responses with accurate TypeScript examples.
|
|
- Use functional, declarative programming. Avoid classes.
|
|
- Prefer iteration and modularization over duplication.
|
|
- Use descriptive variable names with auxiliary verbs (e.g., isLoading).
|
|
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
|
|
- Favor named exports for components.
|
|
- Use the Receive an Object, Return an Object (RORO) pattern.
|
|
|
|
## Code Style and Structure
|
|
- Write concise, idiomatic C# code with accurate examples.
|
|
- Follow .NET and ASP.NET Core conventions and best practices.
|
|
- Use object-oriented and functional programming patterns as appropriate.
|
|
- Prefer LINQ and lambda expressions for collection operations.
|
|
- Use descriptive variable and method names (e.g., 'IsUserSignedIn', 'CalculateTotal').
|
|
- Structure files according to .NET conventions (Controllers, Models, Services, etc.).
|
|
|
|
## Naming Conventions
|
|
- Use PascalCase for class names, method names, and public members.
|
|
- Use camelCase for local variables and private fields.
|
|
- Use UPPERCASE for constants.
|
|
- Prefix interface names with "I" (e.g., 'IUserService').
|
|
|
|
## C# and .NET Usage
|
|
- Use C# 10+ features when appropriate (e.g., record types, pattern matching, null-coalescing assignment).
|
|
- Leverage built-in ASP.NET Core features and middleware.
|
|
- Use MongoDb and Influxdb effectively for database operations.
|
|
|
|
## Syntax and Formatting
|
|
- Follow the C# Coding Conventions (https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions)
|
|
- Use C#'s expressive syntax (e.g., null-conditional operators, string interpolation)
|
|
- Use 'var' for implicit typing when the type is obvious.
|
|
|
|
## Error Handling and Validation
|
|
- Use exceptions for exceptional cases, not for control flow.
|
|
- Implement proper error logging using built-in .NET logging or a third-party logger.
|
|
- Use Data Annotations or Fluent Validation for model validation.
|
|
- Implement global exception handling middleware.
|
|
- Return appropriate HTTP status codes and consistent error responses.
|
|
|
|
## API Design
|
|
- Follow RESTful API design principles.
|
|
- Use attribute routing in controllers.
|
|
- Implement versioning for your API.
|
|
- Use action filters for cross-cutting concerns.
|
|
|
|
## Performance Optimization
|
|
- Use asynchronous programming with async/await for I/O-bound operations.
|
|
- Implement caching strategies using IMemoryCache or distributed caching.
|
|
- Use efficient LINQ queries and avoid N+1 query problems.
|
|
- Implement pagination for large data sets.
|
|
|
|
## Testing
|
|
- Write unit tests using xUnit.
|
|
- Use Mock or NSubstitute for mocking dependencies.
|
|
- Implement integration tests for API endpoints.
|
|
|
|
## Security
|
|
- Give me advice when you see that some data should be carefully handled
|
|
|
|
## API Documentation
|
|
- Use Swagger/OpenAPI for API documentation (as per installed Swashbuckle.AspNetCore package).
|
|
- Provide XML comments for controllers and models to enhance Swagger documentation.
|
|
|
|
React/Tailwind/DaisyUI
|
|
- Use functional components and TypeScript interfaces.
|
|
- Use declarative JSX.
|
|
- Use function, not const, for components.
|
|
- Use DaisyUI Tailwind Aria for components and styling.
|
|
- Implement responsive design with Tailwind CSS.
|
|
- Use mobile-first approach for responsive design.
|
|
- Place static content and interfaces at file end.
|
|
- Use content variables for static content outside render functions.
|
|
- Minimize 'use client', 'useEffect', and 'setState'. Favor RSC.
|
|
- Wrap client components in Suspense with fallback.
|
|
- Use dynamic loading for non-critical components.
|
|
- Optimize images: WebP format, size data, lazy loading.
|
|
- Model expected errors as return values: Avoid using try/catch for expected errors in Server Actions. Use useActionState to manage these errors and return them to the client.
|
|
- Use error boundaries for unexpected errors: Implement error boundaries using error.tsx and global-error.tsx files to handle unexpected errors and provide a fallback UI.
|
|
- Use useActionState with react-hook-form for form validation.
|
|
- Code in services/ dir always throw user-friendly errors that tanStackQuery can catch and show to the user
|
|
|
|
## Do not forget
|
|
- Always implement the method that you created
|
|
- Before creating new object or new method/function check if there a code that can be called
|
|
- Most the time you will need to update multiple layer of code files. Make sure to reference all the method that you created when required
|
|
- When you think its necessary update all the code from the database to the front end
|
|
- Do not update ManagingApi.ts, once you made a change on the backend endpoint, execute the command to regenerate ManagingApi.ts on the frontend; cd src/Managing.Nswag && dotnet build
|
|
- Do not reference new react library if a component already exist in mollecules or atoms
|
|
- After finishing the editing, build the project
|
|
|
|
Follow the official Microsoft documentation and ASP.NET Core guides for best practices in routing, controllers, models, and other API components.
|