Strict null checks and safety in Typescript - Time & Space Complexity
We want to see how strict null checks affect the speed of TypeScript code.
How does adding safety checks change how long the code takes to run?
Analyze the time complexity of the following code snippet.
function findNameLength(name: string | null): number {
if (name === null) {
return 0;
}
return name.length;
}
const names: (string | null)[] = ["Alice", null, "Bob", "Charlie"];
const lengths = names.map(findNameLength);
This code checks each name for null before getting its length, ensuring safety.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The map function loops over each item in the array.
- How many times: Once for each element in the names array.
Each name is checked once, so the work grows directly with the number of names.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 checks and length reads |
| 100 | About 100 checks and length reads |
| 1000 | About 1000 checks and length reads |
Pattern observation: The number of operations grows evenly as the input grows.
Time Complexity: O(n)
This means the time to run grows in a straight line with the number of items checked.
[X] Wrong: "Adding null checks makes the code much slower, like doubling the time."
[OK] Correct: Null checks add a tiny step per item, but the overall time still grows evenly with input size, not doubling or squaring.
Understanding how safety checks affect performance shows you can write code that is both safe and efficient, a skill valued in real projects.
"What if we changed the array to include nested arrays of names? How would the time complexity change?"
Practice
What does enabling strictNullChecks in TypeScript do?
Solution
Step 1: Understand strictNullChecks purpose
EnablingstrictNullChecksmakes TypeScript require explicit handling ofnullandundefinedvalues to avoid runtime errors.Step 2: Analyze options
Only It forces you to explicitly handlenullandundefinedvalues. correctly describes this behavior. Options B, C, and D are incorrect because they describe behaviors thatstrictNullChecksdoes not do.Final Answer:
It forces you to explicitly handlenullandundefinedvalues. -> Option DQuick Check:
strictNullChecks = explicit null handling [OK]
- Thinking nulls are automatically converted
- Assuming null checks are disabled
- Believing null can be assigned anywhere
Which of the following is the correct way to check for null or undefined before accessing a variable value in TypeScript with strictNullChecks enabled?
let value: string | null | undefined;
Solution
Step 1: Understand null and undefined checks
WithstrictNullChecks, you must check bothnullandundefinedexplicitly before accessing properties.Step 2: Evaluate each option
if (value !== null && value !== undefined) { console.log(value.length); } correctly checks bothnullandundefined. if (value) { console.log(value.length); } may fail ifvalueis an empty string. console.log(value.length); causes an error. if (value == null) { console.log(value.length); } checks for null but then accesses length inside the if, which is incorrect logic.Final Answer:
if (value !== null && value !== undefined) { console.log(value.length); } -> Option AQuick Check:
Check both null and undefined explicitly [OK]
- Using only if(value) which fails on empty strings
- Accessing properties without checks
- Using == null but then accessing inside that block
What will be the output of the following TypeScript code with strictNullChecks enabled?
function greet(name: string | null) {
if (name === null) {
return "Hello, guest!";
}
return `Hello, ${name.toUpperCase()}!`;
}
console.log(greet(null));
console.log(greet("alice"));Solution
Step 1: Analyze null check in function
The function checks ifname === nulland returns "Hello, guest!" in that case, so it safely handles null.Step 2: Check outputs for calls
Callinggreet(null)returns "Hello, guest!". Callinggreet("alice")returns "Hello, ALICE!" becausetoUpperCase()is called on a string.Final Answer:
"Hello, guest!" and "Hello, ALICE!" -> Option BQuick Check:
Null check prevents errors, outputs as expected [OK]
- Expecting runtime error on null
- Thinking compilation error occurs
- Ignoring null check and causing error
Identify the error in this TypeScript code with strictNullChecks enabled and suggest a fix:
function printLength(text: string | null) {
console.log(text.length);
}Solution
Step 1: Identify the error
Accessingtext.lengthwithout checking iftextisnullcauses a compile error understrictNullChecks.Step 2: Suggest fix
Add a check likeif (text !== null)before accessinglengthto ensure safety.Final Answer:
Error: Object is possibly 'null'. Fix: Add a null check before accessinglength. -> Option AQuick Check:
Always check null before property access [OK]
- Ignoring null check and expecting no error
- Changing type instead of fixing code
- Thinking return type causes error
Given this TypeScript function with strictNullChecks enabled, which modification safely handles undefined and null inputs without errors?
function formatName(name: string | null | undefined) {
return name.toUpperCase();
}Solution
Step 1: Identify unsafe code
CallingtoUpperCase()onnamewithout checking fornullorundefinedcauses errors withstrictNullChecks.Step 2: Evaluate options for safety
Add a check:if (name == null) return "Unknown";before callingtoUpperCase(). adds a check for bothnullandundefined(using== null) and returns a default string, safely avoiding errors. Change parameter type tostringonly and remove null and undefined. removes null safety but is less flexible. Use non-null assertion:return name!.toUpperCase();forces non-null assertion which can cause runtime errors. RemovestrictNullChecksfrom tsconfig. disables safety feature, not recommended.Final Answer:
Add a check:if (name == null) return "Unknown";before callingtoUpperCase(). -> Option CQuick Check:
Check null/undefined before method calls [OK]
- Using non-null assertion unsafely
- Removing null from type instead of checking
- Disabling strictNullChecks instead of fixing code
Ready to prove it?
Pass the test and this pattern moves unknown
