High Quality C# - Codequality in Practice
0 likes759 views
The document discusses best practices in C# development, emphasizing the importance of coding standards, documentation, and the use of tools like StyleCop and Roslyn for code quality. It highlights how adherence to established practices and effective documentation can simplify processes and improve team collaboration. The session aims to streamline code quality rules to enhance efficiency, especially in larger teams.
High Quality C# - Codequality in Practice
- 1. Rainer Stropek | software architects High Quality C#
- 2. Introduction • General conditions and processes are important – Requirements Engineering – Project Management (e.g. SCRUM) – Team culture – Processes (e.g. Code Reviews) – Testing (automated and manual) – Tools • In this session we focus on the core C# code, not the surrounding processes
- 3. Why are coding standards important? • Code is easier to understand for new team members (internal and external) – Example: Try… naming schema • Shared or Weak Code Ownership gets easier • Contracts – Obligation to document – Clause „state of the art“ • Simpler, cleaner contracts – Freelancers, subcontractors • Avoid worst practices, follow proven practices – More robust, less error-prone code
- 4. Tools (examples) • Microsoft – C# warnings – Visual Studio Code Analysis – New possibilities of the Roslyn platform • Community – StyleCop – Sandcastle • Commercial 3rd party tools – ReSharper
- 5. StyleCop • Analyzes C# source code to enforce style and consistency rules • Runs in Visual Studio and during build
- 8. Documentation • Not to underestimate – Drives acceptance by end users • What is good documentation? – Conceptual content – Examples – Not just generated text – Completeness
- 11. Code Analysis • Analyzes managed code assemblies • Enforces design rules of Microsoft’s Framework Design Guidelines
- 14. StyleCop & Code Analysis in Build Process
- 15. Roslyn • New compiler framework • Compiler as a service
- 17. Roslyn Demo
- 18. Summary • Automate code quality rules as far as possible – Saves a lot of time especially in larger teams – Code quality rules documented in a stand-alone text file will not be read • Use proven best practices instead of developing everything from scratch – Stop discussing! • Customize tooling to your needs – Not all rules make sense for all projects (e.g. legacy code vs. new code)