In today's world, complexity is everywhere. I mean, look at the cover photo of this post - that's how much complexity airline pilots have to deal with when they're piloting. What gives? One who is familiar with design principles might argue, "Keep It Simple, Silly" and then go on to try and abstract a lot of the internal implementation details and proceed to build simple systems. It works, good for people who use abstracted systems for their simple use cases. However, for advanced use cases, people still need to understand internal workings. That's where the core of the complexity is located in any functional systems.
Why are we talking about systems theory? I mean, aren't we supposed to talk about code complexity? Isn't that the central theme of this post? Well, I'm getting there. I am just hinting at the theory of complexity in modern systems design for a thought experiment. In that line of theorizing computational complexity, at least in my experience as a developer in the past decades, a couple of things come to my mind. One is cyclomatic complexity in conjunction with Big O notation, and the other being a SonarSource™ term that is cognitive complexity. So in lieu with complexity in systems theory and looking at any computational system, if you are dealing with any such systems, having a level deep understanding can serve you well.
Enough of this, "show me the code" you say? Well, this isn't that kind of a post. We will eventually look at pseudo code. However, we will start by looking at different types of complexity below...
Cyclomatic Complexity
If I were to define cyclomatic complexity, it goes like this: "The cyclomatic complexity of a code section is the quantitative measure of the number of linearly independent paths in it." The computational theory behind this is Finite Automata. If you are a CS grad, you would recollect learning about CFG (Control Flow Graph), which is a directed graph. If in a code, a command is followed by another command, that would mean the cyclomatic complexity is 1, since two edges in the graph are linearly connected.
The Mathematical Foundation
The cyclomatic complexity is calculated using the formula:
M = E - N + 2P
Where:
- E = Number of edges in the control flow graph
- N = Number of nodes in the control flow graph
- P = Number of connected components (for a single program, P is usually 1)
Practical Example
Let's look at a simple function and calculate its cyclomatic complexity:
function calculateGrade(score) {
if (score >= 90) {
return 'A';
} else if (score >= 80) {
return 'B';
} else if (score >= 70) {
return 'C';
} else if (score >= 60) {
return 'D';
} else {
return 'F';
}
}
Control Flow Graph Analysis:
- Nodes (N): 6 (1 entry + 4 conditions + 1 exit)
- Edges (E): 5 (4 if-else paths + 1 default)
- Components (P): 1
Cyclomatic Complexity = 5 - 6 + 2(1) = 1
This function has a cyclomatic complexity of 1, which is excellent! It's generally used for evaluating the understandability, testability, and maintainability of a program.
When Complexity Becomes Problematic
Here's an example of high cyclomatic complexity:
function processUserData(user, permissions, settings, context) {
let result = null;
if (user.isActive) {
if (user.hasPermission('read')) {
if (permissions.includes('admin')) {
if (settings.allowAdminAccess) {
if (context.isSecure) {
if (user.lastLogin > Date.now() - 86400000) {
if (user.role === 'superuser') {
result = processSuperUserData(user);
} else if (user.role === 'admin') {
result = processAdminData(user);
} else if (user.role === 'user') {
result = processUserData(user);
} else {
result = processGuestData(user);
}
} else {
result = handleExpiredSession(user);
}
} else {
result = handleInsecureContext(user);
}
} else {
result = handleAdminAccessDenied(user);
}
} else {
result = handleInsufficientPermissions(user);
}
} else {
result = handleNoReadPermission(user);
}
} else {
result = handleInactiveUser(user);
}
return result;
}
This function has a cyclomatic complexity of 13, which is considered high and indicates potential maintainability issues.
Big O Notation
Here we go, a term to comprehend, eh? If I throw the textbook at this: "Big O notation, written as O(f(n)), describes an upper bound on the time complexity of an algorithm in terms of the function f(n), where n is the size of the input. It provides the worst-case performance of an algorithm, indicating how its run time (or space) grows as the size of the input increases."
That's a lot! Let's explain that in layman's terms: Big O notation provides an asymptotic upper bound for the growth rate of a function, typically with respect to the worst-case scenario. It gives an understanding of how the function's performance will scale as the input size grows, especially as it approaches infinity.
Common Big O Notations in Ascending Complexity
| Complexity | Name | Description | Example |
|---|---|---|---|
| O(1) | Constant | Execution time doesn't change with input size | Array access, Hash table lookup |
| O(log n) | Logarithmic | Execution time grows logarithmically | Binary search, Balanced tree operations |
| O(n) | Linear | Execution time grows linearly with input size | Linear search, Array iteration |
| O(n log n) | Linearithmic | Execution time grows as n times log n | Merge sort, Quick sort (average case) |
| O(n²) | Quadratic | Execution time grows quadratically | Bubble sort, Nested loops |
| O(2ⁿ) | Exponential | Execution time grows exponentially | Recursive Fibonacci, Traveling salesman |
Practical Examples
O(1) - Constant Time:
function getFirstElement(array) {
return array[0]; // Always takes the same time regardless of array size
}
O(n) - Linear Time:
function findElement(array, target) {
for (let i = 0; i < array.length; i++) {
if (array[i] === target) {
return i;
}
}
return -1; // Time grows linearly with array size
}
O(n²) - Quadratic Time:
function bubbleSort(array) {
for (let i = 0; i < array.length; i++) {
for (let j = 0; j < array.length - i - 1; j++) {
if (array[j] > array[j + 1]) {
[array[j], array[j + 1]] = [array[j + 1], array[j]];
}
}
}
return array; // Time grows quadratically with array size
}
Why Big O Matters in Practice
Consider you're building a feature that needs to search through user data:
- O(n) approach: Linear search through 1 million users = 1 million operations
- O(log n) approach: Binary search through 1 million users = ~20 operations
The difference is 50,000x faster! This is why understanding algorithmic complexity is crucial for building scalable applications.
Check out the Big O Cheat Sheet for a comprehensive reference of time and space complexities for common algorithms and data structures. It's an excellent resource for quick lookups during interviews and algorithm design.
Cognitive Complexity
If you are a developer and ever worked with spaghetti code, you would have experienced cognitive load on your brain. This is a well-known effect of cognitive complexity. Cognitive complexity is a measure of how difficult a code section is to understand. While metrics like cyclomatic complexity focus on the structural aspects of code, cognitive complexity seeks to evaluate the cognitive load it places on the programmer.
What Makes Code Cognitively Complex?
- Nested Conditionals: Deep if-else chains
- Boolean Logic: Complex boolean expressions
- Switch Statements: Multiple case branches
- Loops: Nested loops and complex loop conditions
- Method Chaining: Long chains of method calls
- Ternary Operators: Nested ternary operators
Example: High Cognitive Complexity
function calculateDiscount(customer, order, promotion) {
let discount = 0;
if (customer.isVIP && customer.membershipYears > 5) {
if (order.total > 1000) {
if (promotion.isActive && promotion.type === 'seasonal') {
if (order.items.some(item => item.category === 'electronics')) {
discount = Math.min(order.total * 0.25, 500);
} else if (order.items.some(item => item.category === 'clothing')) {
discount = Math.min(order.total * 0.20, 300);
} else {
discount = Math.min(order.total * 0.15, 200);
}
} else if (promotion.isActive && promotion.type === 'loyalty') {
discount = Math.min(order.total * 0.10, 100);
} else {
discount = Math.min(order.total * 0.05, 50);
}
} else if (order.total > 500) {
discount = Math.min(order.total * 0.10, 100);
} else {
discount = Math.min(order.total * 0.05, 25);
}
} else if (customer.isRegular && customer.membershipYears > 2) {
if (order.total > 500) {
discount = Math.min(order.total * 0.08, 80);
} else {
discount = Math.min(order.total * 0.03, 15);
}
}
return discount;
}
This function has high cognitive complexity because:
- Deep nesting (up to 4 levels)
- Complex boolean conditions
- Multiple decision points
- Mixed business logic
Refactored: Lower Cognitive Complexity
function calculateDiscount(customer, order, promotion) {
const discountRules = {
vip: {
highValue: { rate: 0.25, max: 500 },
mediumValue: { rate: 0.10, max: 100 },
lowValue: { rate: 0.05, max: 50 }
},
regular: {
highValue: { rate: 0.08, max: 80 },
lowValue: { rate: 0.03, max: 15 }
}
};
const customerType = customer.isVIP && customer.membershipYears > 5 ? 'vip' : 'regular';
const orderValue = getOrderValueCategory(order.total);
const baseRule = discountRules[customerType][orderValue];
let discount = Math.min(order.total * baseRule.rate, baseRule.max);
// Apply promotion adjustments
if (promotion.isActive) {
discount = applyPromotionDiscount(discount, promotion, order);
}
return discount;
}
function getOrderValueCategory(total) {
if (total > 1000) return 'highValue';
if (total > 500) return 'mediumValue';
return 'lowValue';
}
function applyPromotionDiscount(baseDiscount, promotion, order) {
if (promotion.type === 'seasonal' && hasElectronics(order)) {
return Math.min(baseDiscount * 1.5, 500);
}
return baseDiscount;
}
function hasElectronics(order) {
return order.items.some(item => item.category === 'electronics');
}
The Impact on Developer Experience
High cognitive complexity directly impacts:
- Code Review Time: Complex code takes longer to review and understand
- Bug Introduction: More complex code has higher bug density
- Maintenance Cost: Simple code is easier to modify and extend
- Onboarding: New team members struggle with complex codebases
- Refactoring: Complex code is harder to refactor safely
Best Practices for Managing Complexity
1. Single Responsibility Principle
Each function should do one thing well. Break complex functions into smaller, focused functions.
2. Early Returns
Reduce nesting by using early returns and guard clauses:
// Instead of deep nesting
function processUser(user) {
if (user.isActive) {
if (user.hasPermission('read')) {
if (user.role === 'admin') {
return processAdmin(user);
} else {
return processRegularUser(user);
}
} else {
return handleNoPermission(user);
}
} else {
return handleInactiveUser(user);
}
}
// Use early returns
function processUser(user) {
if (!user.isActive) {
return handleInactiveUser(user);
}
if (!user.hasPermission('read')) {
return handleNoPermission(user);
}
if (user.role === 'admin') {
return processAdmin(user);
}
return processRegularUser(user);
}
3. Extract Complex Conditions
Move complex boolean logic into well-named functions:
// Instead of
if (user.isActive && user.hasPermission('read') && user.lastLogin > Date.now() - 86400000) {
// do something
}
// Use
if (canAccessSystem(user)) {
// do something
}
function canAccessSystem(user) {
return user.isActive &&
user.hasPermission('read') &&
user.lastLogin > Date.now() - 86400000;
}
4. Use Data Structures
Replace complex conditionals with lookup tables or maps:
// Instead of long if-else chains
function getDiscountRate(customerType) {
if (customerType === 'vip') return 0.25;
if (customerType === 'premium') return 0.15;
if (customerType === 'regular') return 0.10;
if (customerType === 'basic') return 0.05;
return 0;
}
// Use a map
const DISCOUNT_RATES = {
vip: 0.25,
premium: 0.15,
regular: 0.10,
basic: 0.05
};
function getDiscountRate(customerType) {
return DISCOUNT_RATES[customerType] || 0;
}
Tools and Metrics
Static Analysis Tools
- SonarQube: Comprehensive code quality analysis
- ESLint: JavaScript/TypeScript linting with complexity rules
- PMD: Java static analysis
- RuboCop: Ruby code analysis
Recommended Thresholds
- Cyclomatic Complexity: Keep functions under 10
- Cognitive Complexity: Keep functions under 15
- Function Length: Keep functions under 50 lines
- Nesting Depth: Keep nesting under 3 levels
Conclusion
Understanding and managing code complexity is crucial for building maintainable, scalable software. While some complexity is inevitable in real-world applications, being aware of the different types of complexity and having strategies to manage them can significantly improve code quality and developer productivity.
The key takeaways:
- Cyclomatic complexity measures structural complexity and helps identify testing needs
- Big O notation helps understand algorithmic performance and scalability
- Cognitive complexity measures how hard code is to understand and maintain
- Simple code is better code - prioritize readability and maintainability
As they say in my hometown, don't forget to be awesome! And remember, the best code is the code that's easiest to understand, not necessarily the most clever.