One outcome of bad code is that you can end up with a really badly written piece of code that is hard to understand. This can often lead to programmer stress and software that is buggy, hard to maintain, and hard to test and extend.
One outcome of good code is that it is easy to read and understand, as you know the programmer's intent. This leads to less stress for programmers who must debug the code, test it, and extend it.
When you break a large project up into modular components and libraries, each module can be worked on by separate teams concurrently. Small modules are easy to test, code, document, deploy, extend, and maintain.
DRY stands for Don't Repeat Yourself. Look for repeatable code, and refactor it so that you remove duplicate code. The advantage of this is smaller programs, because if such code contains bugs, you only have to change it in one place.
KISS means simple code that will not confuse programmers, especially if you have juniors on your team. KISS code is easy to read and write tests for.
S is the Single Responsibility Principle, O is the Open/Closed Principle, L is Liskov Substitution, I is the Interface Segregation Principle, and D is the Dependency Inversion Principle.
YAGNI is short for You Aren't Going to Need It. In other words, don't add code you don't need. Only add the code you absolutely need, and no more.
Occam's Razor is the principle that states: Entities must not be multiplied without necessity.Deal only in facts. Only make assumptions if absolutely necessary.
Chapter 2
The two roles in the peer code review are reviewer and reviewee.
The project manager agrees on the people that will be involved in the peer code review.
You can save your reviewer time and effort prior to requesting a peer code review by making sure your code and tests all work, that you perform code analysis on your project and fix any issues raised, and that your code adheres to the company coding guidelines.
When reviewing code, look out for naming, formatting, programming styles, potential bugs, correctness of code and tests, security, and performance issues.
The three categories of feedback are positive, optional, and critical.
Chapter 3
We can place our code in individual source files in folder structures and wrap classes, interfaces, structs, and enums in namespaces that map to the folder structure.
A class should have only one responsibility.
You can comment in your code for document generators using XML comments placed directly above the public member to be documented.
Cohesion is the logical grouping together of code that works on the same responsibility.
Coupling refers to the dependencies between classes.
Cohesion should be high.
Coupling should be low.
You can use DI and IoC to design for change.
DI stands for Dependency Injection.
IoC stands for Inversion of Control.
Immutable objects are type-safe and so can be safely passed between threads.
Objects should expose methods and properties and hide data.
Data structures should expose data and have no methods.
Chapter 4
Methods with no parameters are called niladic methods.
Methods with only one parameter are called monadic methods.
Methods with two parameters are called dyadic methods.
Methods with three parameters are called triadic methods.
Methods with more than three parameters are called polyadic methods.
You should avoid duplicate code. It is not a productive way to program, can make programs unnecessarily large, and has the propensity to proliferate the same exception throughout your codebase.
Functional programming is a software coding methodology that treats computations as the mathematical evaluation of computations that does not modify state.
The advantages of functional programming include safe code in multithreaded applications and smaller, more meaningful methods that are easy to read and understand.
Input and output can be a problem for functional programs as it relies on side-effects. Functional programming does not allow for side-effects.
WET code is the opposite of DRY in that code is written each time it is needed. This produces duplication, and the same exception can occur in multiple locations within a program, making maintenance and support more difficult.
DRY code is the opposite of WET in that code is only ever written once and is reused wherever it is needed. This reduces the code base and exception footprint, thus making programs easier to read and maintain.
You DRY out WET code by removing duplicate code using refactoring.
Long methods are cumbersome and prone to exceptions. The smaller they are, the easier they are to read and maintain. There is also less chance of the programmer introducing bugs, especially of a logical nature.
To avoid having to use try/catch blocks, you can write argument validators. You would then call the validators at the top of your method. If the parameters fail validation, then the appropriate exception is thrown, and the method is not executed.
Chapter 5
A checked exception is an exception that is checked at compile time.
An unchecked exception is an exception that is not checked or simply ignored at compile time.
An overflow exception is raised when high-order bits cannot be assigned to the destination type. In checked mode, OverflowException is raised. In unchecked mode, high-order bits that cannot be assigned are simply ignored.
An attempt made to access a property or a method on a null object.
Implement a Validator class and an Attribute class that checks the parameter for null, and that throws ArgumentNullException. You would use the Validator class at the top of your methods so that you don't get halfway through the method before the exception is raised.
Business Rule Exception (BRE).
BREs are bad practice because they expect exceptions to be raised in order to control program flow.
Correct programming should never control the flow of a computer program by expecting exceptions as output. So, given that BREs are bad as they expect exceptional output and use it to control program flow, a better solution is to use conditional programming. With a conditional program, you use Boolean logic. Boolean logic allows for two possible paths of execution, and never raises exceptions. Conditional checks are explicit and make the programs easier to read and maintain. You can also easily extend such code, whereas with BREs, you can't.
First, start with error trapping for known types of exceptions such as ArgumentNullExceptions and OverflowExceptions using known exception types in the Microsoft .NET Framework. But when these are insufficient and don't provide enough data for your particular situation, then you would write and use your own custom exceptions and apply meaningful exception messages.
Your custom exception must inherit from System.Exception, and implement three constructors: the default construct, a constructor that accepts a text message, and a constructor that accepts a text message and an inner exception.
Chapter 6
A good unit test must be atomic, deterministic, repeatable, and fast.
A good unit test must not be inconclusive.
Test-driven development.
Behavioral-driven development.
A small unit of code whose only purpose is to test a single unit of code that only does one thing.
A fake object used by the unit test to test the public methods and properties of a real object, but without testing the method or property dependencies.
A fake object is the same as a mock object.
MSTest, NUnit, and xUnit.
Rhino Mocks and Moq.
SpecFlow.
Unnecessary comments, dead code, and redundant tests.
Chapter 7
The testing of a complete system from end to end. This can be performed manually, automatically, or by using both methods.
Integration testing.
Manual testing of all features, all our unit tests should pass, and we should write automation tests to test the commands and data that are passed between two modules.
Factories are classes that implement the factory method pattern whose intention is to allow the creation of objects without specifying their classes. We would use them in the following scenarios:
The class is unable to anticipate the type of object that must be instantiated.
The subclass must specify the type of object to instantiate.
The class controls the instantiation of its objects.
DI is a method of producing loosely coupled code that is easy to maintain and extend.
Using a container makes the management of dependency objects easy.
Chapter 8
A thread is a process.
One.
Background threads and foreground threads.
The background thread.
The foreground thread.
Thread.Sleep(500);
var thread = new Thread(Method1);
Set IsBackground equal to true.
A deadlock is a situation when two threads are blocked and waiting on the other thread to release the resource.
Monitor.Exit(objectName);
Multiple threads using the same resource generate different outputs based on the timings of each thread.
Use the TPL with ContinueWith(), and use Wait() to wait until the task has finished before exiting the method.
Using a member variable that is shared by other methods, and passing in reference variables.
Yes.
The ThreadPool.
It is an object that cannot be modified once it has been constructed.
They allow you to safely share data between threads.
Hypermedia as the Engine of Application State (HATEOAS).
RapidApi.com.
Authorization and authentication.
Claims are statements that an entity makes about itself. These claims are then validated against a data store. They are particularly useful in role-based security to check whether the entity making the claim is authorized in regard to that claim.
Making API requests and examining their responses.
Because you can change your data store in keeping with your requirements.
Chapter 10
The correct partitioning of software into logical namespaces, interfaces, and classes, which aids the testing of software.
By understanding APIs, you can KISS your code and keep it DRY by not reinventing the wheel and writing code that already exists. This saves time, energy, and money.
Structs.
Third-party APIs are written by software developers, and so subject to human error that introduces bugs. By testing third-party APIs, you can be confident they work as expected, and if not, then you can have the code fixed or write a wrapper for it.
Your APIs are prone to errors. By testing them in keeping with the specification and its acceptance criteria, you can be sure you are delivering what the business wants at the agreed level of quality ready for public release.
The specification and acceptance criteria provide the normal program flow. From them, you can determine what to test in regard to the normal flow of execution, and you can determine what exceptional circumstances will be encountered and test for them.
Namespaces, interfaces, and classes.
Chapter 11
Cross-cutting concerns are those concerns that not part of the business requirements that form the core concerns, but that must be addressed in all areas of the code. AOP stands for Aspect-Oriented Programming.
An aspect is an attribute that, when applied to a class, method, property, or parameter, injects code at compile time. You apply an aspect in square brackets before the item it is being applied to.
An attribute gives semantic meaning to an item. You apply an attribute in square brackets before the item it is being applied to.
Attributes give the code semantic meaning, while aspects remove the boilerplate code so that it is injected at compile time.
When the code is being built, the compiler will insert the boilerplate code that the aspect hides from the programmer. This process is known as code weaving.
Chapter 12
Code metrics are several source code measurements that enable us to identify how complex our software is, and how maintainable it is. Such measurements enable us to identify areas of code that can be made less complex and more maintainable through refactoring.
Cyclomatic complexity, maintainability index, depth of inheritance, class coupling, lines of source code, and lines of executable code.
Code analysis is the static analysis of source code with the intention of identifying design flaws, issues with globalization, security problems, issues with performance, and interoperability problems.
Quick actions are single commands identified by a screwdriver or lightbulb that will suppress warnings, add using statements, import missing libraries and add the using statements, correct errors, and implement language usage improvements aimed at simplifying code and reducing the number of lines in a method.
JetBrains' dotTrace utility is a profiling tool used for the purpose of profiling source code and compiled assemblies to identify potential issues with the software. With it you can perform sampling, tracing, line-by-line, and timeline profiling. You can profile execution time, thread time, real-time CPU instructions, and thread cycle time.
JetBrains' ReSharper utility is a code refactoring tool that helps developers identify and fix code issues and implement language features to improve and speed up the programmer's programming experience.
The decompilation of source code can be used to retrieve lost source code, generate PDBs for debugging, and for learning. You can also use the decompiler to see how well you have obfuscated your code to make it hard for hackers and other people to steal your code secrets.
Chapter 13
Application-level, class-level, and method-level.
Boolean blindness, combinatorial explosion, contrived complexity, data clump, deodorant comments, duplicate code, lost intent, mutation of variables, oddball solution, shotgun surgery, solution sprawl, and uncontrolled side effects.
Cyclomatic complexity, divergent change, downcasting, excessive literal use, feature envy, inappropriate intimacy, indecent exposure, large class (also known as God object), lazy class (also known as freeloader and lazy object), middleman class, an orphan class of variables and constants, primitive obsession, refused bequest, speculative generality, Tell, don't ask!, and temporary field.
Black sheep, cyclomatic complexity, contrived complexity, dead code, excessive data return, feature envy, identifier size, inappropriate intimacy, long line aka God line, lazy method, long method (God method), long parameter list (too many parameters), message chains, middleman method, oddball solutions, and speculative generality.
Use LINQ instead of loops. Make classes responsible for only one thing. Make methods do only one thing. Replace long lists of parameters with parameter objects. Use creational design patterns to improve the efficiency of expensive object creation and utilization. Keep methods to 10 lines or less. Use AOP to remove boilerplate code from methods. Decouple objects and make them testable. Make code highly cohesive.
A value that represents the amount of branching and looping.
Reduce the amount of branching and looping that takes place until such time as the cyclomatic complexity value becomes 10 or less.
Making things more complicated than they need to be.
Keep It Simple, Stupid (KISS).
The same thing is done by different methods with different parameter combinations.
Create generic methods that can perform the same task on the different data types so that you only have the one method with one set of parameters.
Fix the bad code and remove the comment.
Ask for help.
Stack Overflow.
A long parameter list can be replaced with a parameter object.
Refactor it into smaller methods that do only one thing, and remove boilerplate code into aspects using AOP.
No more than 10 lines.
0-10; anything beyond that and you are asking for trouble.
One.
Variables, classes, properties, and methods that are not used. Get rid of them.
Choose the best method of implementation, and then refactor the code to use just that method of implementation.
Refactor the temporary field and the methods that operate on it into their own class.
The same set of variables used in different classes. Refactor the variables into a class of their own, and then reference the class.
A class inherits from another class but does not use all its methods.
The Law of Demeter.
Only allow classes to speak to their immediate neighbors.
A class or method spending too much time inside another class or method.
Refactor dependencies in their own class or method.
The factory method.
Inherit from a base class, and then create the new class that inherits from the base.
Single responsibility is implemented in different methods of different classes across different layers of the application. Refactor the responsibility into its own class so that it is only in a single location.
The data should be placed in the same object that operates on it.
When you create an object that asks another object for data so that it can perform operations on it.
A single change requires changes in multiple locations. Remove duplication, remove the coupling, and improve cohesion.
Lost intent is when the reason for the class or method is unclear because there are lots of unrelated items clumped together. Refactor the code so that all methods are in the right class. That way, the intent of the class and the methods becomes clear.
You can refactor loops with LINQ queries. LINQ is a functional language that does not alter location variables and can perform much faster than loops.
Chapter 14
GoF is short for Gang-of-Four patterns. These are 23 patterns that are grouped into creational, structural, and behavioral design patterns. They are considered the foundation of all software design patterns. They work together to produce clean object-oriented code.
Creational patterns enable abstraction and inheritance to provide an object-oriented way of removing code duplication and improving performance when object creation is expensive. The creational patterns are abstract factory, factory method, singleton, prototype, and builder.
Structural patterns enable the correct management of relationships between objects. We can use structural patterns to enable incompatible interfaces to work together, decouple abstractions from their implementations, and improve performance. The structural patterns are adapter, bridge, composite, decorator, façade, flyweight, and proxy.
Behavioral patterns govern how objects interact and communicate with each other. We can use them to produce pipelines, encapsulate commands and information to be executed at a future point in time, mediate between objects, observe state changes in objects, and more. The behavior patterns are chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method, and visitor.
Yes.
The singleton only allows a single instance of an object throughout the lifetime of the application. The object is globally accessible to all objects that need it. We use this pattern when we need to ensure we have one centralized point of object creation and object access.
We use factory methods when we have a need to create objects without specifying the exact class to be instantiated.
Façade.
Use the flyweight design pattern.
Bridge.
Use the builder pattern.
You would use the chain of responsibility pattern, as you can have a pipeline of handlers, each of which performs a task. If they are unable to handle the task, the handlers pass the task to their successor to handle.
