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

Content preview from Clean Code in C#

Securing APIs with API Keys and Azure Key Vault

In this chapter, we are going to see how we can keep secrets in Azure Key Vault. We will also be looking at how we can use API keys to secure our own keys with authentication and role-based authorization. To gain first-hand experience with API security, we will build a fully functional FinTech API.

Our API will extract third-party API data using a private key (kept safe in Azure Key Vault). We will then secure our API with two API keys; one key will be used internally and a second key will be used by external users.

The following topics are covered in this chapter: