Class Design Design Naming Exception Handling

Single Responsibility Principle (SRP) Keep Configurable Data At High Levels Choose Descriptive / Unambiguous Names Catch Specific Exceptions
A class should have one, and only one, reason to change. If you have a constant such as default or configuration value that is known Names have to reflect what a variable, field, property stands for. Names Catch exceptions as specific as possible. Catch only the exceptions for
and expected at a high level of abstraction, do not bury it in a low-level have to be precise. which you can react meaningful.
Open Closed Principle (OCP) function. Expose it as an argument to the low-level function called from
You should be able to extend a classes behavior, without modifying it. the high-level function.
Choose Names At Appropriate Level Of Abstraction Catch Exceptions Where You Can React Meaningful
Choose names that reflect the level of abstraction of the class or method Only catch exceptions when you can react in a meaningful way.
Liskov Substitution Principle (LSP) Don’t Be Arbitrary you are working in. Otherwise, let someone up in the call stack react to it.
Derived classes must be substitutable for their base classes. Have a reason for the way you structure your code, and make sure that
reason is communicated by the structure of the code. If a structure
Name Interfaces After Functionality They Abstract Using Exceptions for Control Flow
Interface Segregation Principle (ISP) appears arbitrary, others will feel empowered to change it. The name of an interface should be derived from ist usage by the client, Using exceptions for control flow: has bad performance, is hard to
Make fine grained interfaces that are client specific. like IStream. understand, results in very hard handling of real exceptional cases.
Be Precise Name Classes After Implementation
Dependency Inversion Principle (DIP) When you make a decision in your code, make sure you make it precisely. Swallowing Exceptions
Depend on abstractions, not on concretions. The name of a class should reflect how it fulfills the functionality provided Exceptions can be swallowed only if the exceptional case is completely
Know why you have made it and how you will deal with any exceptions. by its interface(s), like MemoryStream : IStream resolved after leaving the catch block. Otherwise, the system is left in an
Package Cohesion Name Methods After What They Do inconsistent state.
Release Reuse Equivalency Principle (RREP) Structure Over Convention The name of a method should describe what is done, not how it is done.
The granule of reuse is the granule of release. Enforce design decisions with structure over convention. Source Layout
Naming conventions are good, but they are inferior to structures that Use Long Names For Long Scopes Vertical Separation
Common Closure Principle (CCP) force compliance. fields à parameters à locals à loop variables Variables and methods should be defined close to where they are used.
Classes that change together are packaged together. long à short Local variables should be declared just above their first usage and should
Prefer Polymorphism To If/Else Or Switch/Case
Common Reuse Principle (CRP) “ONE SWITCH”: There may be no more than one switch statement for a Names Should Describe Side-Effects have a small vertical scope.
given type of selection. The cases in that switch statement must create Names have to reflect the entire functionality.
Classes that are used together are packaged together. Use Explanatory Variables
polymorphic objects that take the place of other such switch statements
in the rest of the system.
Avoid Encodings In Names Use locals to give steps in algorithms names.
Package Coupling No prefixes, no type/scope information
Acyclic Dependencies Principle (ADP) Symmetry / Analogy Nesting
The dependency graph of packages must have no cycles Favour symmetric designs (e.g. Load – Safe) and designs the follow Use Standard Nomenclature Where Possible Nested code should be more specific or handle less probable scenarios
analogies (e.g. same design as found in .NET framework). than unnested code.
Stable Dependencies Principle (SDP) Understandability
Depend in the direction of stability. Misplaced Responsibility Consistency
Something put in the wrong place. Separate Multi-Threading Code
If you do something a certain way, do all similar things in the same way:
Stable Abstractions Principle (SAP) same variable name for same concepts, same naming pattern for
Do not mix code that handles multi-threading aspects with the rest of
Abstractness increases with stability. Code At Wrong Level Of Abstraction the code. Separate them into different classes.
Clean Code

Functionality is at wrong level of abstraction, e.g. a PercentageFull corresponding concepts

property on a generic IStack<T>. Conditionals
General Poorly Written Comment
Follow Standard Conventions Fields Not Defining State Comment does not add any value (redundant to code), is not well Encapsulate Conditionals
Coding-, Architecture-, Design-Guidelines (check them with tools) Fields holding data that does not belong to the state of the instance but formed, not correct grammar/spelling if ([Link](timer)) is preferable to if ([Link] &&
are used to hold temporary data. Use local variables or extract to class ![Link])
Keep it simple, stupid (KISS) Obscured Intent
abstraction the performed action. Too dense algorithms that loose all expressivness. Avoid Negative Conditionals
Simpler is always better. Reduce complexity as much as possible. Negative conditionals are harder to read than positive conditionals.
Over Configurability Obvious Behaviour Is Unimplemented
Boy Scout Rule Prevent configuration just for the sake of it – or because nobody can Encapsulate Boundary Conditions
Leave the campground cleaner than you found it. Violations of “the Principle of Least Astonishment”
decide how it should be. Otherwise, this will result in too complex, What you expect is what you get Boundary conditions are hard to keep track of. Put the processing for
instabile systems. them in one place.
Root Cause Analysis Hidden Logical Dependency
Always look for the root cause of a problem. Otherwise, it will get you E.g. nextLevel = level + 1;
Dependencies A method can only work correctly when invoked correctly depending on
again and again. something else in the same class, e.g. a DeleteItem method must only be
Avoid Transitive Navigation Useless Stuff
Multiple Languages In One Source File aka Law of Demeter, Writing shy code called if a CanDeleteItem method returned true, otherwise it will fail.
Dead Comment, Code
XML, HTML, XAML, English, German, JavaScript, … A module should know only its direct dependencies. Just delete not used things
Methods
Environment Make Logical Dependencies Physical Methods Should Do One Thing Clutter
If one module depends upon another, that dependency should be
Project Build Requires Only One Step physical, not just logical. Don’t make assumptions.
loops, exception handling, … Code that is not dead but does not add any functionality.
Check out and then build with a single command encapsulate in sub-methods
Singletons / Service Locator Inappropriate Information
Executing Tests Requires Only One Step Methods Should Descend 1 Level Of Abstraction Comment holding information better held in a different kind of system:
Use dependency injection. Singletons hide dependencies. The statements within a method should all be written at the same level of
Run all unit tests with a single command product backlog, source control
Base Classes Depending On Their Derivatives abstraction, which should be one level below the operation described by Use comments for technical notes only.
Source Control System Base classes should work with any derived class. the name of the function.
Always use a source control system. Maintainability Killers
Too Much Information Method With Too Many Arguments
Continuous Integration Prefer less arguments. Maybe functionality can be outsourced to Duplication
minimize interface to minimize coupling Eliminate duplication. Violation of the „Don’t repeat yourself“ (DRY)
Assure integrity with Continuous Integration dedicated class that holds the information in fields.
Feature Envy principle.
Overridden Safeties Method With Out/Ref Arguments
The methods of a class should be interested in the variables and functions Prevent usage. Return complex object holding all values, split into several Magic Numbers / Strings
Do not override Warnings, Errors, Exception Handling – they will catch of the class they belong to, and not the variables and functions of other Replace Magic Numbers with named constants.
you. methods. If your method must change the state of something, have it
classes. When a method uses accessors and mutators of some other change the state of the object it is called on.
object to manipulate the data within that object, then it envies the scope Enums (persistent or defining behaviour)
Dependency Injection of the class of that other object. It wishes that it were inside that other Selector / Flag Arguments Use reference codes instead of enums if they have to be persisted.
Decouple Construction from Runtime class so that it could have direct access to the variables it is manipulating. public int Foo(bool flag) Use polymorphism instead of enums if they define behaviour.
Decoupling the construction phase completely from the runtime helps to split method into several independent methods that can be called from
simplify unit tests. the client without the flag.
Artificial Coupling
Things that don’t depend upon each other should not be artificially Inappropriate Static Practices Smells V 1.3
coupled. Static method that should be an instance method.
Author: Urs Enzler
Hidden Temporal Coupling
If for example the order of some method calls is important then make
sure that they cannot be called in the wrong order.