Software Developer Principles and Practices

Single Responsibility Principle (SRP)

A class should have only one reason to change, meaning it has a single responsibility or concern.

Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification.

Liskov Substitution Principle (LSP)

Base classes should be substitutable for their derived classes without affecting the execution or correctness of the program.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces or methods they do not use.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules; both should depend on abstractions.

Inversion of Control (IoC)

A design principle where code delegates the creation and binding of dependencies to an external framework or container.

Explicit Dependencies Principle (EDP)

Classes and methods should explicitly request any collaborators they need via public constructors or method parameters.

Abstraction

Hiding complex implementation details and showing only the essential features of an object through contracts.

Encapsulation

Bundling data with methods into a single unit while restricting direct external access to internal state.

Compile-Time Polymorphism

Resolving method calls at compile time through method overloading or operator overloading without requiring inheritance.

Runtime Polymorphism

Resolving method calls at runtime using inheritance alongside virtual and override keywords.

Inheritance

Reusing code by allowing a child class to inherit properties and behaviors from a parent class.

Composition

Building complex objects by combining smaller objects ("has-a" relationship) rather than inheriting from base classes.

Delegation

An object-oriented practice where an object hands off responsibility for a task to another object or method.

Delegate

A type-safe C# object that holds a reference to one or more methods matching a specific signature.

Func

A predefined C# delegate for a method that takes zero or more parameters and returns a value of type T.

Action

A predefined C# delegate for a method that takes zero or more parameters and returns void.

Predicate

A predefined C# delegate that takes exactly one parameter of type T and always returns a boolean.

Event

A specialized delegate wrapper that enables multicast notifications while restricting external code to subscribing and unsubscribing only.

Covariance (out)

Allows substituting a more derived type in output or return positions of generic interfaces and delegates.

Contravariance (in)

Allows substituting a less derived (more general) type in input parameter positions of generic interfaces and delegates.

Invariance

Strictest generic typing where no type substitution is allowed, requiring exact type matching for both inputs and outputs.

Task

A reference type in .NET representing an asynchronous operation or a future result.

ValueType (ValueTask)

A struct in .NET that represents an async operation or completed result to reduce heap memory allocations.

Pure Function

A function that always returns the same output for the same input and produces no side effects.

DRY Principle

"Don't Repeat Yourself"—a practice focused on reducing code duplication across a system.

KISS Principle

"Keep It Simple, Stupid"—a design rule prioritizing simplicity over unnecessary complexity.

YAGNI Principle

"You Ain't Gonna Need It"—a guideline to avoid implementing features until they are strictly needed.

Pareto Principle (80/20 Rule)

The observation that roughly 80% of outcomes or defects stem from 20% of causes or core features.

REST

Representational State Transfer—an architectural style for designing stateless, networked client-server applications.

CRUD

Create, Read, Update, Delete—the four fundamental operations for persistent data management.

Primitive Obsession

A code smell where primitive data types are overused to represent domain concepts instead of dedicated value objects.

Magic Strings

Hard-coded string values used directly in business logic without central definition or compile-time checking.

Magic Numbers

Unexplained, hard-coded numeric literals used directly in logic without named constants.

Principle of Least Privilege

Granting a module or user only the minimum access rights required to perform their function.

Principle of Least Surprise

Designing software components to behave in ways that users and developers intuitively expect.

Law of Demeter

Also known as the Principle of Least Knowledge; states that a module should only communicate with its immediate collaborators.

Fail Fast Principle

Detecting invalid states or errors as early as possible and halting execution immediately to simplify debugging.

Postel's Law

The Robustness Principle: be conservative and strict in what you output, but liberal and flexible in what you accept as input.