book

Clean Code in C#

by Jason Alls

July 2020

Intermediate to advanced

500 pages

11h 8m

English

Packt Publishing

Read now

Unlock full access

Clean Code in C#
Why subscribe?
About the authorAbout the reviewerPackt is searching for authors like you
Who this book is forWhat this book coversTo get the most out of this bookDownload the example code filesDownload the color imagesConventions usedGet in touchReviews
Technical requirementsGood code versus bad codeBad codeImproper indentationComments that state the obviousComments that excuse bad codeCommented-out lines of codeImproper organization of namespacesBad naming conventionsClasses that do multiple jobsMethods that do many thingsMethods with more than 10 lines of codeMethods with more than two parametersUsing exceptions to control program flowCode that is difficult to readCode that is tightly coupledLow cohesionObjects left hanging aroundUse of the Finalize() methodOver-engineeringLearn to Keep It Simple, StupidLack of regions in large classesLost-intention codeDirectly exposing informationGood codeProper indentationMeaningful commentsAPI documentation commentsProper organization using namespacesGood naming conventionsClasses that only do one jobMethods that do one thingMethods with less than 10 lines, and preferably no more than 4Methods with no more than two parametersProper use of exceptionsCode that is readableCode that is loosely coupledHigh cohesionObjects are cleanly disposed ofAvoiding the Finalize() methodThe right level of abstractionUsing regions in large classesThe need for coding standards, principles, and methodologiesCoding standardsCoding principlesCoding methodologiesCoding conventionsModularityKISSYAGNIDRYSOLIDOccam's RazorSummaryQuestionsFurther reading
The code review processPreparing code for reviewLeading a code reviewIssuing a pull requestResponding to a pull requestEffects of feedback on revieweesKnowing what to reviewCompany's coding guidelines and business requirement(s)Naming conventionsFormattingTestingArchitectural guidelines and design patternsPerformance and securityKnowing when to send code for reviewProviding and responding to review feedbackProviding feedback as a reviewerResponding to feedback as a revieweeSummaryQuestionsFurther reading
Technical requirementsOrganizing classes A class should have only one responsibilityCommenting for documentation generationCohesion and couplingAn example of tight couplingAn example of low couplingAn example of low cohesionAn example of high cohesionDesign for changeInterface-oriented programmingDependency injection and inversion of controlAn example of DIAn example of IoCThe Law of Demeter A good and a bad example (chaining) of the Law of DemeterImmutable objects and data structuresAn example of an immutable typeObjects should hide data and expose methodsAn example of encapsulationData structures should expose data and have no methodsAn example of data structureSummaryQuestionsFurther reading
Understanding functional programmingKeeping methods smallIndenting codeAvoiding duplicationAvoiding multiple parametersImplementing SRPSummaryQuestionsFurther reading

Checked and unchecked exceptionsAvoiding NullPointerExceptionsBusiness rule exceptionsExample 1 – handling conditions with business rule exceptionsExample 2 – handling conditions with normal program flowExceptions should provide meaningful informationBuilding your own custom exceptionsSummaryQuestionsFurther reading
Technical RequirementsUnderstanding the reasons for a good testUnderstanding the testing toolsMSTestNUnitMoqSpecFlowTDD methodology practice – fail, pass, and refactorRemoving redundant tests, comments, and dead codeSummaryQuestionsFurther reading
E2E testingThe login module (subsystem)The admin module (subsystem)The test module (subsystem)Testing our three-module system using E2EFactoriesDependency injectionModularizationSummaryQuestionsFurther reading
Understanding the thread life cycleAdding thread parametersUsing a thread poolTask Parallel LibraryParallel.Invoke()Parallel.For()ThreadPool.QueueUserWorkItem()Using a mutex with synchronous threadsWorking with parallel threads using semaphoresLimiting the number of processors and threads in the thread poolPreventing deadlocksCoding a deadlock examplePreventing race conditionsUnderstanding static constructors and methods Adding static constructors to our sample codeAdding static methods to our sample codeMutability, immutability, and thread safetyWriting code that is mutable and not thread-safeWriting code that is immutable and thread-safe Understanding thread safetySynchronized method dependenciesUsing the Interlocked classGeneral recommendationsSummaryQuestionsFurther reading
Technical requirementsWhat is an API?API proxiesAPI design guidelinesWell-defined software boundariesUnderstanding the importance of good quality API documentation Swagger API developmentPassing immutable structs instead of mutable objectsTesting third-party APIsTesting your own APIsAPI design using RAMLInstalling Atom and API Workbench by MuleSoftCreating the projectGenerating our C# API from our agnostic RAML design specificationSummaryQuestionsFurther reading
Technical requirementsUndertaking the API project – dividend calendarAccessing the Morningstar APIStoring the Morningstar API key in Azure Key VaultCreating the dividend calendar ASP.NET Core web application in AzurePublishing our web applicationUsing an API key to secure our dividend calendar APISetting up the repositorySetting up authentication and authorizationAdding authenticationAdding authorizationTesting our API key securityAdding the dividend calendar codeThrottling our API SummaryQuestionsFurther reading
Technical requirementsThe decorator patternThe proxy patternAOP with PostSharpExtending the aspect frameworkDeveloping our aspectInjecting behaviors before and after the method executionExtending the architectural frameworkProject – cross-cutting concerns reusable libraryAdding the caching concernAdding file logging capabilitiesAdding the logging concernAdding the exception-handling concernAdding the security concernAdding the validation concernAdding the transaction concernAdding the resource pool concernAdding the configuration settings concernAdding the instrumentation concernSummaryQuestionsFurther reading
Technical requirementsDefining good-quality codePerforming code cleanup and calculating code metrics Performing code analysisUsing quick actionsUsing the JetBrains dotTrace profilerUsing JetBrains ReSharperUsing Telerik JustDecompileSummaryQuestionsFurther reading
Technical requirementsApplication-level code smellsBoolean blindnessCombinatorial explosionContrived complexityData clumpDeodorant comments Duplicate codeLost intentThe mutation of variablesThe oddball solutionShotgun surgerySolution sprawlUncontrolled side effectsClass-level code smellsCyclomatic complexityReplacing switch statements with the factory patternImproving the readability of conditional checks within an if statementDivergent changeDowncastingExcessive literal useFeature envyInappropriate intimacyIndecent exposureThe large class (aka the God object)The lazy class (aka the freeloader and the lazy object)The middleman classThe orphan class of variables and constantsPrimitive obsessionRefused bequestSpeculative generalityTell, Don't AskTemporary fieldsMethod-level smellsThe black sheep methodCyclomatic complexityContrived complexityDead codeExcessive data returnFeature envyIdentifier sizeInappropriate intimacyLong lines (aka God lines)Lazy methodsLong methods (aka God methods)Long parameter lists (aka too many parameters)Message chainsThe middleman methodOddball solutionsSpeculative generalitySummaryQuestionsFurther reading
Technical requirementsImplementing creational design patternsImplementing the singleton patternImplementing the factory method patternImplementing the abstract factory patternImplementing the prototype patternImplementing the builder patternImplementing structural design patternsImplementing the bridge patternImplementing the composite patternImplementing the façade patternImplementing the flyweight patternOverview of behavioral design patternsFinal thoughtsSummaryQuestionsFurther reading
Chapter 1Chapter 2Chapter 3Chapter 4Chapter 5Chapter 6Chapter 7Chapter 8Chapter 9Chapter 10Chapter 11Chapter 12Chapter 13Chapter 14
Leave a review - let other readers know what you think

Overview

"Clean Code in C#" is your essential guide to writing professional, maintainable, and efficient C# code. Through practical examples and expert insights, this book will equip you with the skills to refactor legacy systems and implement best practices to produce clean, readable, and scalable code.

What this Book will help me do

Understand and apply clean coding principles to write readable and maintainable C# code.
Perform effective code reviews to align with industry coding standards.
Master test-driven development and ensure robust software delivery.
Design secure and well-structured APIs using advanced tools.
Refactor legacy code to improve performance and scalability.

Author(s)

Jason Alls is an experienced C# developer with many years in the software development industry. His work focuses on creating efficient, innovative software solutions. Jason is passionate about clean code and dedicated to sharing best practices through his teaching and writing. This book captures his deep understanding of software artistry.

Who is it for?

This book is designed for C# developers, senior engineers, team leads, and software architects eager to refine their coding practices. It's ideal for readers with foundational knowledge of C# programming who aspire to improve software maintainability and system performance. Whether you work on legacy codebases or modern solutions, this book will guide you in writing excellent code.