clean-code-dotnet

Applies clean code principles to .NET and ABP application development.

Updated May 22, 2026
One-click install
npx skills add https://github.com/shakesoft/timekeeper --skill clean-code-dotnet-shakesoft
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: clean-code-dotnet
Source: https://github.com/shakesoft/timekeeper/tree/main/.cursor/skills/clean-code-dotnet
Command: npx skills add https://github.com/shakesoft/timekeeper --skill clean-code-dotnet-shakesoft

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? .NET and ABP codebases often accumulate inconsistent naming, bloated methods, and architectural anti-patterns like business logic in controllers or direct DbContext access in app services. This Skill provides a concrete reference of clean code rules so developers write consistent, maintainable ABP code from the start. ## Core Features & Use Cases - Naming Conventions: Standard patterns for entities, DTOs, app services, interfaces, private fields, constants, and permission strings. - SOLID in ABP Context: Maps each SOLID principle to concrete ABP practices such as injecting IRepository<T> instead of DbContext. - Async and Repository Rules: Enforces async database operations, proper Async suffix usage, and repository pattern boundaries. - Anti-Pattern Detection: Lists common mistakes like returning entities from app services or missing [AbpAuthorize] attributes, with their fixes. - Use Case: While writing a new ProductAppService, consult the Skill to confirm DTO naming, authorization attributes, tenant ID handling, and method size limits before committing code. ## Quick Start Review my new ABP app service against the clean code rules and point out any anti-patterns or naming violations.

Frequently Asked Questions about clean-code-dotnet

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply clean code principles in ABP framework apps?▼

Follow naming conventions like {Entity}AppService and {Entity}Dto, keep methods under 30 lines, and inject IRepository<T> instead of DbContext. Map entities to DTOs before returning them from app services and add [AbpAuthorize] to all public methods.

What naming conventions should .NET ABP app services follow?▼

Entities use PascalCase, DTOs follow {Entity}Dto or Create{Entity}Dto, app services use {Entity}AppService, and interfaces use I{Name}. Private fields use _camelCase and permissions follow the Pages_{Area}_{Feature}_{Action} pattern.

Should app services use DbContext or IRepository in ABP?▼

App services should inject IRepository<T> for standard CRUD operations and never access DbContext directly from the Application layer. Custom repositories are only justified for complex queries that IRepository cannot express.

When should async methods use the Async suffix in .NET?▼

Suffix async methods with Async only for interface methods according to these conventions. All database operations must be async, and you should never call .Result or .Wait() on async code.

What are common ABP anti-patterns to avoid?▼

Common anti-patterns include business logic in controllers, returning entities instead of DTOs, direct DbContext usage in app services, hardcoded error messages instead of L("Key"), missing [AbpAuthorize] attributes, and not setting TenantId from AbpSession after mapping.