Clean code in C# : refactor your legacy C# code base and improve application performance by applying best practices

Cover -- Title Page -- Copyright and Credits -- Dedication -- About Packt -- Contributors -- Table of Contents -- Preface -- Chapter 1: Coding Standards and Principles in C# -- Technical requirements -- Good code versus bad code -- Bad code -- Improper indentation -- Comments that state the obvious -- Comments that excuse bad code -- Commented-out lines of code -- Improper organization of namespaces -- Bad naming conventions -- Classes that do multiple jobs -- Methods that do many things -- Methods with more than 10 lines of code -- Methods with more than two parameters -- Using exceptions to control program flow -- Code that is difficult to read -- Code that is tightly coupled -- Low cohesion -- Objects left hanging around -- Use of the Finalize() method -- Over-engineering -- Learn to Keep It Simple, Stupid -- Lack of regions in large classes -- Lost-intention code -- Directly exposing information -- Good code -- Proper indentation -- Meaningful comments -- API documentation comments -- Proper organization using namespaces -- Good naming conventions -- Classes that only do one job -- Methods that do one thing -- Methods with less than 10 lines, and preferably no more than 4 -- Methods with no more than two parameters -- Proper use of exceptions -- Code that is readable -- Code that is loosely coupled -- High cohesion -- Objects are cleanly disposed of -- Avoiding the Finalize() method -- The right level of abstraction -- Using regions in large classes -- The need for coding standards, principles, and methodologies -- Coding standards -- Coding principles -- Coding methodologies -- Coding conventions -- Modularity -- KISS -- YAGNI -- DRY -- SOLID -- Occam's Razor -- Summary -- Questions -- Further reading -- Chapter 2: Code Review - Process and Importance -- The code review process -- Preparing code for review -- Leading a code review ; Issuing a pull request -- Responding to a pull request -- Effects of feedback on reviewees -- Knowing what to review -- Company's coding guidelines and business requirement(s) -- Naming conventions -- Formatting -- Testing -- Architectural guidelines and design patterns -- Performance and security -- Knowing when to send code for review -- Providing and responding to review feedback -- Providing feedback as a reviewer -- Responding to feedback as a reviewee -- Summary -- Questions -- Further reading -- Chapter 3: Classes, Objects, and Data Structures -- Technical requirements -- Organizing classes -- A class should have only one responsibility -- Commenting for documentation generation -- Cohesion and coupling -- An example of tight coupling -- An example of low coupling -- An example of low cohesion -- An example of high cohesion -- Design for change -- Interface-oriented programming -- Dependency injection and inversion of control -- An example of DI -- An example of IoC -- The Law of Demeter -- A good and a bad example (chaining) of the Law of Demeter -- Immutable objects and data structures -- An example of an immutable type -- Objects should hide data and expose methods -- An example of encapsulation -- Data structures should expose data and have no methods -- An example of data structure -- Summary -- Questions -- Further reading -- Chapter 4: Writing Clean Functions -- Understanding functional programming -- Keeping methods small -- Indenting code -- Avoiding duplication -- Avoiding multiple parameters -- Implementing SRP -- Summary -- Questions -- Further reading -- Chapter 5: Exception Handling -- Checked and unchecked exceptions -- Avoiding NullPointerExceptions -- Business rule exceptions -- Example 1 - handling conditions with business rule exceptions -- Example 2 - handling conditions with normal program flow ; Exceptions should provide meaningful information -- Building your own custom exceptions -- Summary -- Questions -- Further reading -- Chapter 6: Unit Testing -- Technical Requirements -- Understanding the reasons for a good test -- Understanding the testing tools -- MSTest -- NUnit -- Moq -- SpecFlow -- TDD methodology practice - fail, pass, and refactor -- Removing redundant tests, comments, and dead code -- Summary -- Questions -- Further reading -- Chapter 7: End-to-End System Testing -- E2E testing -- The login module (subsystem) -- The admin module (subsystem) -- The test module (subsystem) -- Testing our three-module system using E2E -- Factories -- Dependency injection -- Modularization -- Summary -- Questions -- Further reading -- Chapter 8: Threading and Concurrency -- Understanding the thread life cycle -- Adding thread parameters -- Using a thread pool -- Task Parallel Library -- Parallel.Invoke() -- Parallel.For() -- ThreadPool.QueueUserWorkItem() -- Using a mutex with synchronous threads -- Working with parallel threads using semaphores -- Limiting the number of processors and threads in the thread pool -- Preventing deadlocks -- Coding a deadlock example -- Preventing race conditions -- Understanding static constructors and methods -- Adding static constructors to our sample code -- Adding static methods to our sample code -- Mutability, immutability, and thread safety -- Writing code that is mutable and not thread-safe -- Writing code that is immutable and thread-safe -- Understanding thread safety -- Synchronized method dependencies -- Using the Interlocked class -- General recommendations -- Summary -- Questions -- Further reading -- Chapter 9: Designing and Developing APIs -- Technical requirements -- What is an API? -- API proxies -- API design guidelines -- Well-defined software boundaries ; Understanding the importance of good quality API documentation -- Swagger API development -- Passing immutable structs instead of mutable objects -- Testing third-party APIs -- Testing your own APIs -- API design using RAML -- Installing Atom and API Workbench by MuleSoft -- Creating the project -- Generating our C# API from our agnostic RAML design specification -- Summary -- Questions -- Further reading -- Chapter 10: Securing APIs with API Keys and Azure Key Vault -- Technical requirements -- Undertaking the API project - dividend calendar -- Accessing the Morningstar API -- Storing the Morningstar API key in Azure Key Vault -- Creating the dividend calendar ASP.NET Core web application in Azure -- Publishing our web application -- Using an API key to secure our dividend calendar API -- Setting up the repository -- Setting up authentication and authorization -- Adding authentication -- Adding authorization -- Testing our API key security -- Adding the dividend calendar code -- Throttling our API -- Summary -- Questions -- Further reading -- Chapter 11: Addressing Cross-Cutting Concerns -- Technical requirements -- The decorator pattern -- The proxy pattern -- AOP with PostSharp -- Extending the aspect framework -- Developing our aspect -- Injecting behaviors before and after the method execution -- Extending the architectural framework -- Project - cross-cutting concerns reusable library -- Adding the caching concern -- Adding file logging capabilities -- Adding the logging concern -- Adding the exception-handling concern -- Adding the security concern -- Adding the validation concern -- Adding the transaction concern -- Adding the resource pool concern -- Adding the configuration settings concern -- Adding the instrumentation concern -- Summary -- Questions -- Further reading -- Chapter 12: Using Tools to Improve Code Quality ; Technical requirements -- Defining good-quality code -- Performing code cleanup and calculating code metrics -- Performing code analysis -- Using quick actions -- Using the JetBrains dotTrace profiler -- Using JetBrains ReSharper -- Using Telerik JustDecompile -- Summary -- Questions -- Further reading -- Chapter 13: Refactoring C# Code - Identifying Code Smells -- Technical requirements -- Application-level code smells -- Boolean blindness -- Combinatorial explosion -- Contrived complexity -- Data clump -- Deodorant comments -- Duplicate code -- Lost intent -- The mutation of variables -- The oddball solution -- Shotgun surgery -- Solution sprawl -- Uncontrolled side effects -- Class-level code smells -- Cyclomatic complexity -- Replacing switch statements with the factory pattern -- Improving the readability of conditional checks within an if statement -- Divergent change -- Downcasting -- Excessive literal use -- Feature envy -- Inappropriate intimacy -- Indecent exposure -- The large class (aka the God object) -- The lazy class (aka the freeloader and the lazy object) -- The middleman class -- The orphan class of variables and constants -- Primitive obsession -- Refused bequest -- Speculative generality -- Tell, Don't Ask -- Temporary fields -- Method-level smells -- The black sheep method -- Cyclomatic complexity -- Contrived complexity -- Dead code -- Excessive data return -- Feature envy -- Identifier size -- Inappropriate intimacy -- Long lines (aka God lines) -- Lazy methods -- Long methods (aka God methods) -- Long parameter lists (aka too many parameters) -- Message chains -- The middleman method -- Oddball solutions -- Speculative generality -- Summary -- Questions -- Further reading -- Chapter 14: Refactoring C# Code - Implementing Design Patterns -- Technical requirements -- Implementing creational design patterns ; Implementing the singleton pattern