To define the specific conditions that must be met for a user story to be considered ‘Done’. They define the scope of the user story.

‘As a [role], I want [feature/action], so that [benefit/value].’

Independent, Negotiable, Valuable, Estimable, Small, and Testable.

A user story should not overlap with or depend on other stories; it should be possible to schedule, implement, and test it on its own.

Because a user story describes requirements, not implementation details or design decisions.

The development team must have enough information to roughly gauge the effort required to complete it.

It must be appropriately sized to be completed within a single Agile iteration or sprint while still delivering meaningful user value.

By defining clear, objective Acceptance Criteria.

The ‘Given [pre-condition] / When [action] / Then [post-condition]’ format.

A User Story summarizes the who, what, and why of a feature; Acceptance Criteria define the observable conditions that determine whether the story is actually ‘Done’.

It creates an ‘illusion of knowing’ or perceptual fluency.

Challenges that make learning feel harder and slower but trigger processes that optimize long-term retention.

The act of actively recalling information from memory.

Spreading out study sessions over increasing intervals of time.

Mixing the practice of different but related topics or skills.

Attempting to solve a problem before being shown the solution makes the mind more receptive to the answer.

ls

cd Documents

cat config.txt

grep 'ERROR' server.log

chmod +x script.sh

mv draft_v1.txt final_version.txt

mkdir src

less manual.txt

cp report.pdf report_backup.pdf

rm temp_data.csv

echo 'Hello World'

wc -l essay.txt

sed 's/apple/orange/g'

TODAY=$(date +%Y-%m-%d)

rm "$FILE"

$#

mkdir build && cd build && cmake ..

cd /deploy/target || exit 1

rm *.tmp

Lists files and directories in the current (or specified) directory

Creates a new directory

Copies a file or directory to a new location

Moves or renames a file or directory

Permanently deletes files or directories

Displays file contents one screen at a time, with scrolling

Prints the contents of a file to standard output

Edits a stream of text — most commonly used for find-and-replace

Searches text and prints lines that match a pattern

Prints the first lines of a file (default: 10)

Prints the last lines of a file (default: 10)

Counts lines, words, and bytes in a file

Sorts lines of text alphabetically (or numerically)

Extracts specific columns or fields from each line of text

Opens an encrypted remote shell session on another machine

Shows an interactive, real-time view of running processes and system resource usage

Prints the absolute path of the current working directory

Changes the read, write, and execute permissions of a file or directory

grep 'ERROR' server.log | wc -l

sort names.txt | uniq

sort names.txt | uniq -c

ps aux | grep tobias

head -3 config.txt | tail -1

ls -S | head -5

sed 's|http://|https://|g' links.txt > links_secure.txt

grep 'ERROR' access.log | sort | uniq

find . -type f | wc -l

ls -t | head -10

cut -d',' -f2 data.csv | sort | uniq

cat readme.txt | tr 'a-z' 'A-Z' > readme_upper.txt

grep -v 'DEBUG' app.log

grep -h 'success' file1.txt file2.txt | sort | uniq

^ (Caret)

$ (Dollar sign)

[...] (Square brackets)

[^...] (Caret immediately after the opening bracket)

\d

\w

\s

. (Dot)

* (Asterisk)

+ (Plus sign)

? (Question mark)

{n} (Curly braces with a number)

(...) (Parentheses)

(?<name>pattern) (or (?P<name>pattern) in Python)

Prints Score: 95, GPA: 3.8 — the f"..." is an f-string that embeds variables inside {}. The :.1f format specifier rounds the float to 1 decimal place.

7 / 2 → 3.5 (float division — always returns a float in Python 3). 7 // 2 → 3 (floor/integer division — like C++’s / for ints).

Raises TypeError: can only concatenate str to str. Python is strongly typed — it refuses to implicitly convert between str and int. Fix: int("5") + 3 → 8 or "5" + str(3) → "53".

Produces [1, 4, 9, 16, 25] — a list comprehension that squares each number from 1 to 5. range(1, 6) is exclusive of the stop value. ** is the exponentiation operator.

Produces [23, 42] — a list comprehension with a filter condition. Only elements where x > 20 are included.

Opens data.txt, reads it line by line, and prints each line with leading/trailing whitespace removed. The with statement is a context manager that automatically closes the file when the block exits, even if an exception occurs.

Prints 0: apple, 1: banana, 2: cherry. enumerate() yields (index, value) pairs — the Pythonic way to get both index and element without using range(len(...)).

Returns ['404', '500'] — a list of strings matching all non-overlapping occurrences of one or more digits (\d+). The r'...' is a raw string that preserves backslashes for the regex engine.

Replaces all IPv4 addresses in text with 'x.x.x.x'. re.sub(pattern, replacement, string) is the Python equivalent of sed 's/old/new/g'.

Prints the error message to stderr (not stdout), then exits with code 1 (failure). file=sys.stderr is like C++’s std::cerr. sys.exit(1) is like C’s exit(1).

2 ** 8 → 256 (exponentiation — two to the eighth power). 2 ^ 8 → 10 (bitwise XOR — NOT exponentiation!). This is a common mistake from math notation.

Gets the first command-line argument. sys.argv[0] is the script name itself (like C’s argv[0]). If no argument is provided, this raises an IndexError.

print(f"Student: {name}, GPA: {gpa:.2f}")

7 // 2

2 ** 10

[x**2 for x in range(1, 6)]

[x for x in nums if x > 20]

re.sub(r'\d+\.\d+\.\d+\.\d+', 'x.x.x.x', text)

print(type(x))

git revert

git diff HEAD

git init

git config

git add <filename>

git status

git commit -m 'message'

git log

git diff

git branch <branch-name>

git switch main

git merge <branch-name>

git clone <url>

git pull

git push

git show <commit-hash>

git switch -c feature-auth

git restore --staged <filename>

git restore <filename>

A fast-forward merge — occurs when ‘main’ has no new commits since the feature branch was created.

let declares a mutable variable (can be reassigned). const declares an immutable binding (cannot be reassigned). Never use var — it has hoisting and scoping bugs.

First: true — == triggers implicit type coercion, converting "1" to 1 before comparing. Second: false — === checks both value AND type with no coercion. Always use ===.

Prints Hello, Alice! — template literals use backticks (`) and ${expression} for interpolation. This is the JavaScript equivalent of Python’s f-strings.

Declares an arrow function that takes one parameter n and returns n * 2. Arrow functions are the modern, concise syntax for anonymous functions.

Produces [2, 4] — .filter() creates a new array containing only elements where the callback returns true. The arrow function is a callback passed as an argument.

Produces 6 — .reduce() accumulates a single value by calling the callback for each element. acc starts at 0 (the second argument) and each step adds n to it.

Object destructuring — extracts the name and grade properties into separate variables: name = "Alice", grade = 95. Equivalent to const name = obj.name; const grade = obj.grade;.

Array destructuring — assigns items by position: lat = 40.7, lng = -74.0. This is the JavaScript equivalent of Python’s tuple unpacking lat, lng = (40.7, -74.0).

Output: A, C, B — NOT A, B, C. The setTimeout callback goes to the Task Queue and only runs when the Call Stack is empty. Synchronous code always completes first, even with a 0ms delay.

An async function that fetches data from an API. await suspends this function (non-blocking — the Event Loop can do other work) until the Promise from fetch() resolves. result.json() also returns a Promise.

Runs fetchA() and fetchB() in parallel and waits for both to finish. Total time = max(A, B), not A + B. Uses array destructuring to assign results.

Produces [2, 4, 6] — .map() transforms each element by calling the callback and returns a new array of results. The original array is unchanged.

console.log() is JavaScript’s equivalent of Python’s print() and C++’s printf(). It writes to stdout with a trailing newline. It can print any value — strings, numbers, objects, arrays.

Creates a Promise manually. The constructor takes a function with two callbacks: resolve(value) — call when work succeeds, reject(error) — call when it fails. In practice you rarely create Promises from scratch; you mostly consume them with await or .then().

result is a Promise, not 42. Every async function always returns a Promise, even when the body just returns a plain value. To get 42, you need await getCount() or getCount().then(n => ...).

Optional chaining ?. safely accesses nested properties — returns undefined instead of throwing if any link is null/undefined. Nullish coalescing ?? provides a default only for null/undefined (unlike ||, which also replaces 0, '', and false).

First prints undefined — a declared variable with no value assigned is undefined. Second prints null — explicitly set to ‘no value’. JavaScript has two ‘nothings’: undefined (missing) and null (intentionally empty). typeof undefined is "undefined", but typeof null is "object" (a famous JS bug).

Prints Alice then 95. Dot notation (student.name) and bracket notation (student["grade"]) both access object properties. Bracket notation is useful when the key is a variable: const key = "grade"; student[key].

JSON.stringify(obj) converts the object to the string '{"name":"Bob","grade":42}'. JSON.parse(json) converts that string back to an object. JSON is the standard format for sending data over HTTP — res.json() in Express calls JSON.stringify for you.

found is { id: 2, name: "Bob" }. .find() returns the first element where the callback returns true, or undefined if no match. Unlike .filter() which returns an array, .find() returns a single element.

JavaScript control flow uses C++-style braces {} (not Python’s colon + indentation). There is no elif — use else if. Braces are required for multi-line blocks.

userInput === 42 or Number(userInput) === 42

`Hello, ${name}! Score: ${score}`

const add = (a, b) => a + b;

const evens = nums.filter(n => n % 2 === 0);

const doubled = nums.map(n => n * 2);

[1, 2, 3, 4, 5].reduce((acc, n) => acc + n, 0)

const { name, grade } = student;

setTimeout(() => { /* code */ }, 0);

const [a, b] = await Promise.all([fetchA(), fetchB()]);

const student = students.find(s => s.id === 2);

A React component — a function that returns JSX. It renders an <h1> with blue text. The double braces in style={{...}} are: outer {} = JSX expression, inner {} = JavaScript object literal.

Renders the ProductCard component with two props: name (string "Laptop") and price (number 999.99). String props use quotes; all other types use {}.

A composable container component. title is a regular prop. children is a special prop containing whatever JSX is nested between <Card> and </Card>. This enables composition over inheritance.

Declares a state variable count with initial value 0 and a setter function setCount. Calling setCount(newValue) triggers a re-render. The array destructuring extracts the pair returned by useState.

A button with a click event handler. When clicked, it calls setCount(count + 1) which updates state and triggers a re-render. Note: onClick (camelCase), not onclick.

Renders an array of <li> elements from the tasks data array using .map(). Each element has a stable key prop (task.id) that helps React’s reconciler track which items changed.

Conditional rendering using a ternary — renders Dashboard if isLoggedIn is true, LoginForm otherwise. This is one of two standard patterns (the other is &&).

Short-circuit conditional rendering — renders Badge ONLY when unreadCount > 0. When the left side is false, React renders nothing. Note: use > 0, not just unreadCount &&, to avoid rendering 0 as text.

Correctly adds newItem to state. Creates a new array with the spread operator (...items copies all existing items, then newItem is appended). You must create a new array — items.push(newItem) mutates in-place and React won’t detect the change.

Passes the state value text as a prop and the setter setText as a callback prop. This is inverse data flow — the child calls onChange(newValue) to notify the parent, which updates state and triggers re-render of both.

A self-closing JSX tag for an image. In JSX, self-closing tags must include the /> (unlike HTML where <img> is valid). src={url} passes a JS variable; alt="logo" passes a string literal.

A reusable component that renders a colored badge. It destructures label and color from props. The style prop takes a JS object with camelCase properties (borderRadius, not border-radius).

Runs a side effect once after the component first mounts. The empty array [] is the dependency array — it tells React ‘don’t re-run this when anything changes’. Common uses: fetching initial data, setting up subscriptions, updating document.title.

Fetches user data on mount and re-fetches whenever userId changes. userId in the dependency array tells React: re-run this effect when userId takes a new value. Without listing userId, the effect would keep showing the first user’s data even after the prop changes — a stale closure bug.

The functional update form of setState. Instead of passing the next value directly, you pass a function. React calls that function with the guaranteed latest state value as prev. Use this whenever new state depends on old state — it prevents stale closure bugs where a batch of rapid updates could all read the same outdated value.

Removes the item with id === targetId from the items state array. .filter() returns a new array (never mutates the original), which is required — React detects changes by reference. All items where the condition is true are kept; the one matching targetId is excluded.

Updates the name field of the user state object while preserving all other fields. The spread ...user copies every existing key into a new object, then name: 'Bob' overrides just that one key. Never mutate the object directly (user.name = 'Bob') — that changes the same reference React already has, so it won’t detect the change and won’t re-render.

A controlled input — React owns the input’s value by binding it to the query state variable. Every keystroke fires onChange, which calls setQuery, which updates state, which causes React to re-render the input with the new value. This makes React the single source of truth for the field’s content, so you can read or validate the value at any time from query.

<div style={{background: "blue", color: "white"}}>Content</div>

const [count, setCount] = React.useState(0);

<button onClick={() => setCount(count + 1)}>+1</button>

{isLoggedIn ? <Dashboard /> : <LoginForm />}

{count > 0 && <Badge count={count} />}

setItems([...items, newItem])

<h1 className="app-title">My App</h1>

setTasks(tasks.filter(task => task.id !== deletedId));

setPlayer({ ...player, score: newScore });

Maintaining a one-to-many dependency between objects efficiently and without tight coupling—when one object changes state, all dependents are notified automatically.

The Pull model, because observers must hold a reference back to the subject and know its interface well enough to query for specific data.

A memory leak where observers register with a subject but are never unsubscribed, causing the subject’s reference to keep them alive in memory.

In code, observers call the subject to register (dependency points observer→subject), but data conceptually flows subject→observer—making it hard to trace what depends on what.

GUI/MVC architectures (model notifies views), event management systems (listeners for events), and social media feeds (followers notified of new posts).

The client consumes resources and initiates contact in the basic request-response model. The server provides resources, listens for incoming requests, and responds. Multiple clients can connect to the same server simultaneously; server-initiated updates require an established channel or an extra mechanism such as WebSockets, server-sent events, or push notifications.

In P2P, there is no central server. Every node is equally privileged and acts as both a supplier and consumer of resources. It is decentralized, so there is no single point of failure — but if a peer goes offline, its unique resources become unavailable.

A hybrid combines client-server and P2P. Apple FaceTime uses hybrid: for 1-on-1 calls it attempts a direct P2P connection for lower latency, falling back to Apple’s relay servers if NAT or firewalls block the direct path. Group FaceTime routes all participants through Apple’s servers to prevent each device from uploading a separate video stream to every other participant.

Throughput = volume of requests processed per unit time (e.g., an API handling 500 req/sec during peak load). Latency = time for a single request to complete (e.g., a database query returning in 40ms). They are not always correlated: adding more servers increases throughput but doesn’t reduce per-request latency. Caching reduces latency and may also increase throughput.

1. Application Layer — your browser constructs the HTTP request (verb, URL, headers). 2. Transport Layer — TCP wraps it in a segment with port numbers and sequence info for reliable delivery. 3. Internet Layer — IP wraps it in a packet with source and destination IP addresses for routing between networks. 4. Link Layer — Ethernet/Wi-Fi wraps it in a frame with MAC addresses and physically transmits it to the next hop.

Each layer wraps the higher-layer message as its payload and adds its own header — like sealing a letter inside successively larger envelopes. An HTTP message (the letter) is placed inside a TCP envelope (labeled with port numbers), which is placed inside an IP envelope (labeled with IP addresses), which is placed inside an Ethernet envelope (labeled with MAC addresses). Each envelope carries only the addressing information needed for that one delivery step.

SYN → SYN-ACK → ACK. The client sends SYN (‘I want to connect’), the server replies SYN-ACK (‘OK, I’m ready’), the client confirms with ACK (‘let’s go’). It ensures both parties are ready to send and receive data before any data is transmitted.

TCP sends data in ordered segments with checksums for error detection. The receiver sends ACKs to confirm receipt (a single ACK can cover multiple segments). If the sender doesn’t receive an ACK within a timeout, it retransmits the missing data. This provides reliable, in-order byte-stream delivery while the connection remains usable; applications still need their own checks for end-to-end business invariants.

Each HTTP request is independent — the server does not remember any information about previous requests from the same client. Every request must contain all the information the server needs to respond. Web apps use cookies/sessions to maintain state across requests.

GET — retrieve a resource. POST — send data for processing, typically to create a new resource. PUT — create or replace the resource at a specific URI (idempotent). DELETE — delete a resource. HEAD — retrieve only the headers of a resource (not the body).

Localhost — a special reserved IP address that always refers to your own machine. During development you might run your Express backend on localhost:5000 and your React frontend on localhost:3000; both processes are on the same machine and communicate without ever touching the public internet.

{protocol}://{domain}(:{port})(/{resource}). Example: http://localhost:5000/courses/cs101. Protocol (http/https), domain (the server’s address), port (which application on the server — optional, defaults to 80/443), resource path (which resource to access — optional, defaults to /).

HTTPS adds TLS encryption, integrity protection, and server authentication to HTTP. It protects sensitive data (passwords, personal info) from being read or modified in transit. Modern web guidance is to serve public pages and subresources over HTTPS, even when the page itself is not collecting sensitive data.

On success, malloc returns a void* pointing to a freshly-allocated block of at least size bytes on the heap. The block’s contents are uninitialized — they hold whatever bytes were last in that memory.

On failure (the OS cannot give you that many bytes), malloc returns NULL.

You must check for NULL before dereferencing the result. Forgetting this check turns an out-of-memory condition into a silent segfault, often far from the actual allocation site.

'\0' is the null terminator — the byte with ASCII value 0. It is not the digit '0', which has ASCII value 48.

Every C string is a char array that ends with '\0'. Library functions in <string.h> (strlen, strcpy, strcmp, …) walk the array byte-by-byte until they hit the terminator — that’s how they know where the string ends, because C strings carry no length metadata.

A char array without a terminator is not a string for these functions; they will read past the end of the array.

C does not mangle function names — every symbol in an object file is the literal name you wrote in the source. Overloading would require encoding parameter types into the symbol name (the C++ approach), which C explicitly avoids.

The tradeoff: C source code has to use distinct names like printInt / printFloat instead of two print overloads, but C symbols are callable from any other language because the symbol you wrote is the symbol the linker sees. This is the main reason almost every language has a clean foreign-function interface to C, but calling into C++ requires extra work to handle mangled names.

char c = 'A' is a single byte holding the ASCII value 65. It lives directly in the variable’s storage.

char* s = "Alice" is a pointer holding the address of the first byte of the string literal "Alice\0" in read-only memory. The literal itself is 6 bytes (5 characters plus the null terminator); s holds an 8-byte address (on a 64-bit system).

Modifying c is fine — it’s an ordinary local variable. Writing through s (e.g., s[0] = 'B') is undefined behavior because string literals live in read-only memory.

Output: n=42 f=3.5 size=4

• %d formats the int.
• %.1f formats the float to 1 decimal place.
• %zu is the format specifier for size_t (the type sizeof returns); on most platforms sizeof(int) is 4.

Negative-transfer trap from C++: mismatched format specifiers (%d for a float, %f for an int) compile cleanly but produce garbage at runtime, because printf blindly trusts the format string. Always compile with -Wall -Wformat to catch this.

void swap(int* a, int* b) {
    int temp = *a;
    *a = *b;
    *b = temp;
}

int main(void) {
    int x = 30, y = 40;
    swap(&x, &y);
    // x is now 40, y is now 30
}

Key points:

• The function dereferences with *a to read or write the caller’s int.
• The call site writes &x, &y — C has no pass-by-reference, so the caller has to take the address explicitly.
• The signature swap(int*, int*) advertises that the function may mutate both arguments. That advertisement is more explicit than C++’s swap(int&, int&).

int* matrix = malloc(rows * cols * sizeof(int));
if (matrix == NULL) {
    fprintf(stderr, "out of memory\n");
    return 1;
}

// Element (i, j) in row-major order:
matrix[i * cols + j] = 42;

free(matrix);
matrix = NULL;        // defensive — turns accidental reuse into a fast segfault

sizeof(int) is needed because malloc takes a byte count, not an element count. Forgetting it (malloc(rows * cols)) would allocate only one byte per element, and the index expression would walk into unrelated memory.

buf is a stack-allocated local array. When greeting returns, that stack frame is reclaimed; the pointer the caller receives points into memory the runtime may reuse for the next function call.

Symptom: Often the call site prints the right string on the first read (because no other function has reused that stack space yet), then garbage after the next function call clobbers the buffer. This is the classic “returns-pointer-to-stack” bug — and because the first read often works, it can ship for months before manifesting under load.

Fix options:

1. Allocate on the heap: char* buf = malloc(64); ...; return buf; — caller must free.
2. Have the caller pass a buffer: void greeting(char* buf, size_t n);.
3. Return a pointer to a static buffer — works but is not thread-safe.

libc is the C standard library. It provides a portable API (fopen, malloc, printf, strlen, …) that your C program calls.

Inside libc, those functions ultimately invoke system calls — privileged operations the kernel performs on behalf of user-space programs. The system-call ABI is different on every operating system (the open syscall on Linux takes different arguments than the equivalent on Windows).

libc papers over those differences. The result: your fopen call compiles into different machine code on Linux vs. macOS vs. Windows, but your source is identical. libc is the layer that makes C source portable across operating systems.

Line 1 allocates 4 bytes on the heap; p holds its address.

Line 2 writes 7 into that block.

Line 3 (free(p)) returns the block to the allocator. The allocator marks it free; the pointer variable p still holds the old address.

Line 4 is a double-free — undefined behavior. Concretely:

• If the allocator has not yet reused that block, it sees a freed entry being freed again and corrupts its internal bookkeeping. The next malloc may return the same address to two callers, or may crash inside the allocator.
• If the block has already been re-allocated to another caller, this free returns their memory to the allocator. They will eventually write through a freed pointer.

Defensive habit: free(p); p = NULL; makes a subsequent free(p) a no-op (the standard guarantees free(NULL) does nothing).

1. Aerospace / medical / safety-critical firmware. NASA’s coding rules restrict flight software to a subset that excludes exceptions and most polymorphism, because hidden control-flow edges (every try block, every virtual call) make it harder for automated verification tools to prove the program meets its specification. C’s smaller, more predictable control-flow graph buys you analyzability.

2. Cross-language library. If you write a high-performance routine that callers in Python, Java, Rust, and Go all need to use, exposing a C ABI is the lingua franca. C symbols are unmangled, so every language’s foreign-function interface can bind to them directly. A C++ library forces every caller to deal with mangled names, ABI versions, and runtime initialization.

Either reason can justify the discipline cost of manual memory management.

Browser JavaScript runs inside a security sandbox that prevents pages from touching your filesystem, hardware, or arbitrary memory. C has unrestricted access to all of those.

If browser JavaScript could call native C functions on your machine, a malicious page could read your private files, drive attached devices, or execute arbitrary code — the entire sandbox guarantee would evaporate.

The modern workaround is WebAssembly: you compile C source to Wasm bytecode, which the browser runs in the same sandbox as JavaScript. Wasm has no syscall access by default — it can only see what the page explicitly hands it. You keep the performance of C without breaking the browser’s security model.

struct list_node {
    int value;
    struct list_node* next;   // self-referential pointer; NULL marks end
};

// Returns a new head whose `next` is the old head; caller owns the returned pointer.
struct list_node* list_prepend(struct list_node* head, int value);

Design choices worth naming:

• The self-reference must be a pointer: struct list_node* next has a fixed pointer size, while embedding a full struct list_node next would require an infinitely large object.
• The function returns a new head rather than mutating in place — this lets the caller chain prepends and handle an empty list (head == NULL) uniformly.
• The doc comment names ownership: the caller must eventually walk the list and free each node.

The tradeoff in one sentence: static linking maximizes portability and run-time predictability at the cost of binary size and update agility; dynamic linking does the reverse. Embedded firmware tends toward static; OS distributions tend toward dynamic.

Design decisions that are likely to change independently should be the secrets of separate modules; the interface between modules should reveal only assumptions that are unlikely to change.

David L. Parnas, in On the Criteria To Be Used in Decomposing Systems into Modules, published in Communications of the ACM.

He compared a conventional flowchart-based decomposition (one module per processing step) and an information-hiding decomposition (one module per design decision) using the KWIC (Key Word In Context) index program. The information-hiding decomposition was dramatically easier to change, understand, and develop in parallel.

An independent unit of work — something that can be assigned to a single engineer or small team and developed in relative isolation. It can be a function, class, package, library, microservice, or subsystem; granularity does not matter.

(1) The interface — the public contract that says what the module does. (2) The implementation (the secret) — the code that says how. The interface should be stable; the implementation should be free to change.

(1) Data structures and formats (array vs. tree vs. hash map); (2) Storage location (local file, SQL, NoSQL, S3, third-party API); (3) Algorithms (greedy vs. DP, A* vs. Dijkstra); (4) External dependencies — libraries, frameworks, vendors (PayPal vs. Stripe, MongoDB vs. Postgres); (5) Hardware and platform details (byte order, screen size, OS APIs).

A deep module hides a lot of complexity behind a small interface (e.g., the file system: open/read/write/close). A shallow module exposes a wide interface that hides little (e.g., a ‘service’ class whose methods one-to-one delegate to another class). Deep modules are the goal; shallow modules are tax.

False. Visibility modifiers are one language tool for enforcing hiding. The principle is broader: even with all-private fields, you can leak the secret through your interface — for example, by returning a vendor-specific type like PayPalCharge from a public method.

Coupling = strength of dependencies between modules — should be low. Cohesion = strength of dependencies within a module — should be high. When secrets are well hidden, coupling drops and cohesion rises.

Syntactic coupling: module A imports/calls/names types from B (the compiler can see it). Semantic coupling: A and B share an unspoken assumption (e.g., ‘phone numbers are 10-digit strings without formatting’); changing the assumption in one silently breaks the other. Semantic coupling is more dangerous because tools can’t detect it.

The secret is ‘we use PayPal’ (the choice of payment provider). It should live in exactly one module — a PaymentGateway interface with a PayPalGateway implementation. OrderService, RefundService, and WalletService should all depend on the abstraction, never on PayPal.

Because clients cannot ignore it. Stateful protocols require clients to maintain a session, reconnect on disconnect, and carry session tokens. Statelessness allows simpler clients. Hiding this would produce mysterious bugs.

Change impact analysis is the procedure of listing plausible future changes, estimating their likelihood, and counting the modules each one would force you to edit. A well-hidden design responds to a single change by lighting up one module; a poorly-hidden one lights up many.

(1) Vendor name in the interface — OrderService.checkoutWithPayPal(...). (2) Returning the implementation type — a repository returning MySQLResultSet instead of List<Order>. (3) Exposed mutable internals — returning a reference to an internal List that callers can mutate.

For throwaway scripts, single-variant systems with stable scope, premature abstractions in domains you don’t yet understand, and performance-critical inner loops where indirection has measurable cost. Also: when the property is genuinely part of the contract and hiding it would produce silent failures.

SoC decides which aspects of the system should live in separate modules. Information Hiding decides how each module protects its design decisions behind a stable interface. SoC without Information Hiding gives you separate modules that still break each other when details change.

Because software systems grew far beyond what one person can understand at once. Faster hardware lets us run larger systems, but architecture makes them understandable: Information Hiding bounds what each developer has to know.

It is the number of possible pairwise relationships among n modules. As module count grows, possible relationships grow roughly quadratically, so uncontrolled dependencies quickly become unmanageable.

Low maintainability, low understandability, and high fragility: small changes touch many unrelated modules, readers must know too much at once, and local edits produce surprising distant bugs.

If a system chooses among several alternatives, only one module should know the exhaustive list of alternatives.

The user-facing checkout flow may need to show PayPal as a supported option, and the server must verify it securely. But backend services should not know the PayPal SDK; they should depend on a vendor-neutral PaymentGateway.

Context and scope, goals and non-goals, the proposed design, and alternatives with trade-offs.

What secret does this module own? If you cannot name a difficult or likely-to-change design decision it hides, the module needs another clear justification or it may be shallow-module overhead.

Examples include file-system layout, disk caching, CPU scheduling, device-driver details, virtual-memory paging, and network-stack internals.

A module guide maps each important secret or responsibility to the module that owns it, so designers and maintainers can quickly find which module should change without reading irrelevant module internals.

Lack of movement — the environment, users, and market change while the software stands still. Ignorant surgery — repeated changes by maintainers who do not understand the original design gradually damage the structure.