Use C# to consider each tip.

Principals

1. High-cohesive, Loose coupling
2. Stick to "Single responsiblity" to keep 1.
3. Improve codes incrementally.

Basics

Naming

• boolean prefix: is,has,can,should
• Use unique, detailed and meaningful vocabulary
• Avoid generic words
• method -> verb for operation, class -> noun as purpose of method
• Separate names in diffirent concerns with detail informations
  • e.g) Product ->　OrderedItem, InventryItem
  • Detect it when you call the noun with different adjectives to express.
• Read Terms of Service.
  • It indicates proper naming and separation of conserns.
• Be Adherent to its business concerns or purposes.
  • Don't stick to technical sections.

Magic numbers

Move literals into constants.

BAD:

for(int i = 0; i < collection.length; i++) {
  if(client[i].age >= 60) {
    ...
  }
}

GOOD:

const int DISCOUNT_AGE = 60;
for(int i = 0; i < collection.length; i++) {
  if(client[i].age >= DISCOUNT_AGE) {
    ...
  }
}

Not NULL

• Don't initialise / pass / return a NULL value
• Set initialised value object

Dead code

• Remove all dead codes
• DON'T comment it out

Logics

Early return / continue / break

Return earlier as much as possible to reduce nests

BAD:

if(isReserved) {
  if(shouldWithGardians) {
    if(client[i].price > client[j]) {
      ...
    }
  }
}

GOOD:

if(!isReserved) {
  return;
}
if(shouldWithGardians) {
  return;
}
if(client[i].price > client[j]) {
  return;
}

...

• Especially useful for writing guard clauses(validation)

Strategy pattern

Use interface to reduce redundant if-else or switch clauses

BAD:

class Shape {
  ...
  int calcArea() {
    readonly int area;
    // you'll add case when you create another Shape.
    switch(type)
    {
      case "Rectangle":
        area = width * height
      case "Triangle":
        area = (width * height) / 2;
      default:
        throw Exception();
    }
    return area;
  }
}

GOOD:

interface Shape {
  ...
  int calcArea();
}

public class Rectangle:Shape {
  ...
  int calcArea() {
    return width * height;
  }
}
public class Triangle:Shape {
  int calcArea(){
    return (width * height) / 2;
  }
}

static void showArea(Shape shape) {
  Console.WriteLine(shape.calcArea());
}

static int main () {
  Shape rectangle = new Rectangle();
  showArea(rectangle);
  Shape triangle = new Triangle();
  showArea(triangle);
}

Policy pattern

Super useful to componentise and assemble a set of conditions.

BAD:

// has dupulicate condition
bool isTriangle(Shape shape){
  if(hasClosedArea(shape)) {
    if(shape.angles.Count() == 3) {
      return true;
    }
  }
  return false;
}

bool isRectangle(){
  if(hasClosedArea(shape)) {
    if(shape.angles.Count() == 4) {
      return true;
    }
  }
  return false;
}

GOOD:

// Create components of rules sharing common interface.
interface ShapeRule() {
  boolean ok(Shape shape);
}

class ClosedAreaRule : ShapeRule {
  boolean ok(Shape shape) { 
    return hasClosedArea(shape);
  }
}

class RectangleAnglesRule : ShapeRule {
  boolean ok(Shape shape) { 
    return shape.angles.Count() == 3;
  }
}

class TrianglesAnglesRule: ShapeRule {
  boolean ok(Shape shape) { 
    return shape.angles.Count() == 4;
  }
}


class ShapePolicy() {
  // Keep set of rules
  private readonly rules = new HashSet<ShapeRule>();

  void AddRules(ShapeRule rule) { 
    rules.Add(rule);
  } 

  // Judge if it meets all conditions
  boolean MeetsAllConditions(Shape shape) {
    rules.All(rule => rule.ok(shape));
  }
}

static int main() {
  // Create rules and combine them as a policy
  ShapeRule closedAreaRule = new ClosedAreaRule();
  ShapeRule triangleAnglesRule = new TrianglesAnglesRule();
  var trianglePolicy = ShapePolicy();
  trianglePolicy.AddRules(closedAreaRule);
  trianglePolicy.AddRules(triangleAnglesRule);

  Shape triangle = new Triangle();

  // Judge by a combined policy
  var isTriangle = trianglePolicy.MeetsAllConditions(triangle);
}

High cohesive

Independent class design

• Integrate relevant variables / methods into a class
• Use INSTANCE variables / methods
• Avoid using STATIC variables / methods
  • Static methods cannot access instance variable
• Use methods to modify its instance valiables
  • Tell, Don't ask
  • Avoid using getter / setter.

Block invalid values on instance variables

• Make sure to initialise on constructor.
• Write input validation on the first of method.
• Pass a parameter as a unique class.
  • Primitive type doesn't notice when you set a invalid value
  • Unique class throws compile error at that time
  • Organises the data structure and reduce the arguments
• Set arguments and variables immutable as much as possible
  • Reassignment can put a invalid value accidentally.
• Return new value object when you modify the instance
• Avoid using output argument
  • It obfuscates where it modified the value

class Price {
  // immutable instance variable
  private readonly int value;

  // immutable argument
  Price(in int value) {
    // input validation
    if(value < 0) {
      throw IlligalArgumentException();
    }
    // initialisation on constructer
    this.value = value;
  }

  Price add(in Price addition) {
    // immutable variable
    readonly int addedValue = this.value + addition.value;
    // return new value object when modification
    return new Price(addedValue);
  }
}

Factory method

Use with private constractor. Set different initial value by different factory methods. Reduce time to search the class with diffirently initicialised instances.

class MemberShip {
  const int STANDERD_FEE = 50;
  const int PREMIUM_FEE = 100;
  private readonly int monthlyFee;

  // private constractor.
  private MemeberShip(in int fee) {
    this.monthlyFee = fee;
  }

  // factory methods are static
  // you only need to investigate this class to modify either of fee
  static createStandardMemberShip() {
    return new MemberShip(STANDERD_FEE);
  }

  static createStandardMemberShip() {
    return new MemberShip(PREMIUM_FEE);
  }
}

First class collection

Collections tends to be scattered and low cohesive.

• Keep collections as private members
• Operate the collection only via methods

Trolley {
  private readonly List<PurchaseItem> items;

  Trolley() {
    items = new List<purchaseItem>();
  }

  // Don't let operate the collection directly
  AddItem(PurchaseItem item) {
    items.Add(item)
  }

  // Return read only instance when you need to provide reference 
  readonly List<PurchaseItem> GetItems() {
    return items
  }
}

Utility class

• Consists of static variables and static methods
• Integrate only something unrelevant to cohesion
  • crosscutting concerns e.g) logging, formatting
• Be careful not to pack unrelevant functionalities.

Loose coupling

Proper separation

• Pay attention to instance variables and separate into another classes.
  • Loose coupling depends on separation of concerns at all.

Proper consolidation

• Don't believe DRY principle blindly.
• Consider if those steps are in the same single responsibility before consolidating them.
• You'll have complex conditional branches inside after all, if you integrate diffirent concerns.

Composition

• Avoid using Inheritance as much as possible.
  • Sub class easily gets unexpected impacts when you modify its super class.
• Use composition instead.

Encupsulation

• Avoid using public blindly.
  • it leads tight coupling.
• Consider if you can configure it as package private(internal) or private
• May use protected when you need to use Inheritance.

Refactoring

Reduce nests

• Early return/continue/break
• Strategy pattern

Proper logic cohesion

• Arrange order
• Chunk steps by purposes
• Extract them into methods

Conditional judgements

• Extract it into methods(is/has/should/can...)
• Combine multiple conditions into a combined methods

Consolidate arguments

• Consolidate multiple arguments on methods into a class
• Realise stamp coupling

Error handling

Catch

• Catch only the error you need to handle
  • Catch business errors
  • Leave System errors
  • Avoid catching plain Exception without any reasons

Handling

Throw errors

• Avoid returning error code.
• Consider rethrowing the error when you need to deligate its handling to caller function.

Logging

• Use logger library
  • Avoid logging into Console without any reasons
• Use detailed error message
  • BAD:"unexpected error occured."
  • GOOD:"the name property is null."

Retry

• Consider when you need to address network delay, DB connection, external service.
• Configure reasonable interval and timeout.
  • interval: Exponential backoff and jitter.
  • timeout: Usually 3 ~ 5 times.
  • Should test if its truly appropriate for your system and adjust it.

Post processing

Release resource

• Don't forget to release opened resource on finally clause.
• e.g.) file, network connection.

Comments

You should only write something you cannot express as code.

Others

Formatting

• 80 characters / line
• Unify tab or space for indent
• Better to configure auto format on IDE

Tools

• Code Climate Quality
• Understand
• Resharper