DEV Community: Grant Riordan

Stop Writing Raw Python - Let C Handle It

Grant Riordan — Sat, 04 Apr 2026 05:07:24 +0000

April 2026 · 6 min read* A .NET developer's guide to Python performance — and why the rules are different

I've spent most of my career in .NET. C#, the CLR, JIT compilation — these are things I know deeply. I'm proficient in TypeScript and JavaScript for full-stack and mobile work. Python, though, has always been at arm's length. I never really needed to cross over into that world.

That changed recently. And the first real thing it taught me was something I hadn't expected: don't write your own raw code if you can help it.

That's strange advice if you're coming from C#. In .NET, hand-crafted code and library code run through the same JIT compiler. Performance is often comparable, so you usually optimise based on other considerations — readability, semantics, maintainability. Python, it turns out, works very differently. Understanding why changes how you write it.

The fundamental difference isn’t syntax — it’s where computation happens. In C#, you trust the JIT to make your code fast. In Python, your job is to keep work out of the Python layer as much as possible.

How Python Actually Runs

The version of Python most people use is CPython — the reference implementation, written in C. When you run a .py file, CPython compiles it to bytecode and then interprets that bytecode at runtime. Crucially, it does not use JIT compilation like C# does.

C# runs on the .NET Common Language Runtime, which uses Just-In-Time (JIT) compilation. Your C# source gets compiled to Intermediate Language (IL), and when you run the program the CLR compiles that IL to native machine code, optimised at runtime. After the initial warm-up, it executes at hardware speed.

CPython is interpreting Python bytecode one instruction at a time. The .NET CLR is handing the CPU something close to its native language.

Worth noting: Python 3.11+ introduced an adaptive interpreter with specialised bytecode — certain hot code paths get micro-optimised at runtime. It's a meaningful improvement, but CPython still lacks a general-purpose JIT. The gap with C# remains significant for CPU-bound work.

This is the root of why Python's raw execution speed is generally slower than C# for CPU-intensive tasks.

The C-Backed Library Trick

Here's where Python gets clever. Many of its built-in functions and popular libraries — sum(), sorted(), itertools (a lazy iterator toolkit), the entirety of NumPy — are not written in Python. They're implemented in C, compiled to native machine code, and called from Python. When you use them, you're escaping the interpreter overhead for the heavy work.

# Slow: a plain Python loop
total = 0
for x in my_list:
    total += x

# Fast: drops into C for the iteration
total = sum(my_list)

A very simple example, but the point holds at scale. Both do the same thing. But the second hands off to a C function that runs without the interpreter touching each iteration. For large lists, the difference is measurable.

The loop isn’t the problem — the Python interpreter touching every iteration is. The fix isn’t to avoid loops specifically, it’s to push computation down into C-backed code wherever possible.

In C#, this asymmetry largely doesn't exist. A hand-rolled loop and Enumerable.Sum() from LINQ go through the same JIT pipeline. That said, LINQ isn't entirely free — it can introduce allocations, delegate overhead, and less predictable inlining. A for loop over an array or Span<T> is often faster in hot paths. But this is an optimisation consideration, not a fundamental runtime difference the way it is in Python.

Vectorisation: The Real Unlock

The "use library functions" advice only scratches the surface. The deeper insight is vectorisation — and it's where the real performance leap happens. The loop example illustrates the principle, but vectorisation is where it gets truly powerful. Not just “C code instead of Python code”, but entire operations that never touch the Python layer at all.

Libraries like NumPy don't just run in C. They operate on entire arrays at once, using CPU-level Single Instruction Multiple Data (SIMD) instructions, avoiding Python-level loops entirely.

import numpy as np

a = np.array([1.0, 2.0, 3.0, 4.0])
b = np.array([10.0, 20.0, 30.0, 40.0])

# This doesn't loop in Python — it's a single C-level vector operation
result = a * b

Compare that to:

# Each iteration is a Python instruction — slow
result = [x * y for x, y in zip(a, b)]

Even though both produce the same output, the NumPy version isn't just "faster C code" — it's a fundamentally different execution model. The Python interpreter barely participates. This is the insight that explains why Python dominates data science and scientific computing despite being a slow language at its core.

Where Does JavaScript Sit?

Coming from .NET, you might assume JavaScript is similarly slow — a scripting language, interpreted, running in a browser. Historically that was fair. Modern JavaScript engines have largely changed the picture.

V8 (powering Chrome and Node.js) uses aggressive JIT compilation with multiple optimisation tiers. JavaScript code that runs frequently gets compiled to native machine code, similar in principle to the .NET CLR. TypeScript compiles to plain JavaScript before anything runs, so at execution time it is identical to JS — no performance difference there.

It's worth noting that JS JIT and C# JIT behave differently in practice. V8 uses speculative optimisation — it makes assumptions about your code and optimises aggressively, but can deoptimise if those assumptions are violated. C#'s CLR is more predictable. Both are fast; JS just requires more care to keep on the happy path.

The practical upshot: the "use library functions or your code will be slow" advice matters much less in JavaScript and TypeScript. A hand-written for loop in modern JS is not dramatically slower than an equivalent library call, because both go through the same JIT compiler.

Where JS does lag is in areas Python has addressed with C-backed scientific libraries. NumPy, Pandas, and similar tools have no real equivalent in the JavaScript ecosystem — or at least, nothing as mature or widely adopted. TensorFlow.js and WebAssembly-based libraries exist, but the gap is significant. If you need serious numerical computing, Python + NumPy will outperform vanilla JS even accounting for Python's slower interpreter, because the actual number crunching never touches the Python layer at all.

A Quick Comparison

Language	Execution Model	Raw Loop Speed	"Use Libraries" Advice
C#	JIT → native machine code (CLR)	Fast	For ergonomics, not speed
Python	Interpreted bytecode (CPython)	Slow	Critical for performance
JavaScript	JIT → native machine code (V8)	Good	For ergonomics, not speed
TypeScript	Compiles to JS → same as JS	Good	Same as JS

Simplified for general application code. Performance is context-dependent. PyPy — a Python implementation with JIT compilation — can significantly close the gap with C# for CPU-bound workloads.

What This Changes About How I Write Python

Knowing this shapes a few concrete habits.

Reach for built-ins first. sum(), map(), sorted(), Counter, list comprehensions — these exist not just for readability, but because they hand off work to C.

NumPy before hand-rolled loops. Any numerical work over arrays belongs in NumPy. Not because it's cleaner (it is), but because it vectorises the operation and keeps it out of the Python interpreter entirely.

Don't be surprised by slow loops. When Python feels slow in a tight loop, that's not a bug in your code — it's the nature of the interpreter. The solution is usually to restructure so the interpreter handles coordination while optimised C code handles the heavy lifting.

For a .NET developer, this is a genuine mental shift. In C#, you trust the JIT to make most sensible code fast. In Python, you trust the libraries to provide fast tools — and your job is to wire them together well.

The Bigger Picture

Python's slowness in raw execution isn't a flaw so much as a design trade-off. The language prioritises readability and developer speed, and it compensates for interpreter overhead by sitting on top of an enormous library of high-performance C code. Once you understand that, a lot of Python idioms that might seem arbitrary start to make perfect sense.

Sometimes you genuinely can’t offload to a library — custom logic, complex conditionals, things NumPy can’t express cleanly. In those cases, accept the performance tradeoff, or reach for generators to manage memory overhead, or PyPy if raw speed is required.

Coming from C# and JavaScript, the biggest adjustment isn’t syntax or semantics. It’s accepting that Python’s performance model is fundamentally different — and that working with it, rather than against it, means trusting the libraries over your own raw code. In C# the JIT has your back. In Python, the libraries do.

Written with a .NET background, a Python curiosity, and one too many slow for loops.

Have thoughts? Leave a comment or find me on X/Twitter.

Stop Writing Python — Let C Do It

Grant Riordan — Fri, 03 Apr 2026 21:20:20 +0000

April 2026 · 6 min read* A .NET developer's guide to Python performance — and why the rules are different

That changed recently. And the first real thing it taught me was something I hadn't expected: don't write your own raw code if you can help it.

How Python Actually Runs

CPython is interpreting Python bytecode one instruction at a time. The .NET CLR is handing the CPU something close to its native language.

Worth noting: Python 3.11+ introduced an adaptive interpreter with specialised bytecode — certain hot code paths get micro-optimised at runtime. It's a meaningful improvement, but CPython still lacks a general-purpose JIT. The gap with C# remains significant for CPU-bound work.

This is the root of why Python's raw execution speed is generally slower than C# for CPU-intensive tasks.

The C-Backed Library Trick

# Slow: a plain Python loop
total = 0
for x in my_list:
    total += x

# Fast: drops into C for the iteration
total = sum(my_list)

The loop isn’t the problem — the Python interpreter touching every iteration is. The fix isn’t to avoid loops specifically, it’s to push computation down into C-backed code wherever possible.

Vectorisation: The Real Unlock

Libraries like NumPy don't just run in C. They operate on entire arrays at once, using CPU-level Single Instruction Multiple Data (SIMD) instructions, avoiding Python-level loops entirely.

import numpy as np

a = np.array([1.0, 2.0, 3.0, 4.0])
b = np.array([10.0, 20.0, 30.0, 40.0])

# This doesn't loop in Python — it's a single C-level vector operation
result = a * b

Compare that to:

# Each iteration is a Python instruction — slow
result = [x * y for x, y in zip(a, b)]

Where Does JavaScript Sit?

A Quick Comparison

Language	Execution Model	Raw Loop Speed	"Use Libraries" Advice
C#	JIT → native machine code (CLR)	Fast	For ergonomics, not speed
Python	Interpreted bytecode (CPython)	Slow	Critical for performance
JavaScript	JIT → native machine code (V8)	Good	For ergonomics, not speed
TypeScript	Compiles to JS → same as JS	Good	Same as JS

Simplified for general application code. Performance is context-dependent. PyPy — a Python implementation with JIT compilation — can significantly close the gap with C# for CPU-bound workloads.

What This Changes About How I Write Python

Knowing this shapes a few concrete habits.

Reach for built-ins first. sum(), map(), sorted(), Counter, list comprehensions — these exist not just for readability, but because they hand off work to C.

The Bigger Picture

Written with a .NET background, a Python curiosity, and one too many slow for loops.

Have thoughts? Leave a comment or find me on X/Twitter.

AI Can Not Be Left Unsupervised

Grant Riordan — Thu, 26 Mar 2026 23:42:34 +0000

"AI is dangerous" — is a phrase you may hear a lot, and I have to agree. But, the most dangerous words in tech right now aren't "AI is dangerous", they're "it'll probably be fine". In a society where the use of AI has become the norm, people have become almost complacent around the dangers of it.

This week I read an article on Dev.to here, telling a story where an employee had "trusted AI to organize my backlog." Two hours later, they returned to a development team's worst nightmare.

"The agent had silently deleted 47 tickets it labelled as duplicates — they weren't. It had reassigned half my team's tasks to people who had left the company months ago. It created 23 new tickets for features nobody had requested. And it marked three critical bugs as resolved, because it found similar-sounding issues elsewhere in the system."

A prime example of when AI is left to its own devices — no warning, no follow-up prompts. It was asked to organise a backlog, and so it did, in the only way it knew how.

Other Damaging Cases

This isn't an isolated incident. Amazon's own AI coding tool, Kiro, was handed a minor fix to a customer-facing system. Rather than patch it, the agent autonomously decided to delete and rebuild the entire environment from scratch. The resulting outage lasted 13 hours. Amazon's response? "Coincidence that AI was involved." That denial tells you everything.

In a similar case, an AI coding assistant from Replit went rogue and wiped the production database of startup SaaStr entirely — its founder took to social media to warn others after the assistant modified production code despite explicit instructions not to.

Could your business afford that kind of downtime?

It isn't just agentic AI operating behind the scenes. Customer-facing AI is failing in equally public and embarrassing ways. DPD's AI chatbot, after a routine system update, began swearing at a customer, insulted itself, and wrote a poem about how terrible the company was, all because a frustrated user simply asked it to. The incident went viral.

Perhaps the most alarming example of AI complacency comes from a Chevrolet dealership, whose chatbot agreed to sell a 2024 Chevy Tahoe for $1 and declared it a legally binding offer after a user simply manipulated it with a clever prompt. The dealer pulled the bot, but the damage to their brand was already done.

In August 2025, security researchers used a single 400-character prompt to manipulate Lenovo's customer service chatbot into revealing sensitive company data including live session cookies from real support agents. Not a sophisticated hack. Just a simple prompt.

Outside of customer service, the professional world is sleepwalking into its own risks. A lawyer was caught citing entirely non-existent legal cases in a New York federal court filing he had used ChatGPT to conduct legal research, and simply trusted the output.

With the rapid adoption of AI across industries, has the world become complacent, siding with productivity over pragmatism? More often than not, users are blindly allowing AI to complete work for them, review sensitive documents outside the bounds of a secure environment, and make decisions without a single human checkpoint.

I know many developers who simply click "Accept" when prompted to approve terminal commands. I've spoken to professionals within my network who say "AI has evolved, it can be trusted." That ignorance and naivety is precisely what leads to the scenarios above.

The companies and individuals that will thrive in an AI-driven world aren't the ones adopting it the fastest. They're the ones adopting it the most responsibly.

Final Note

Before you click "Accept" on that next AI suggestion, ask yourself honestly: do you actually know what you're agreeing to? Don't simply outsource your thinking to something that doesn't think - it predicts.

AI isn't the danger. We are.

I’d love to hear your thoughts - comment below or drop me a follow on X/Twitter

Using Python To Merge Array of Ranges

Grant Riordan — Tue, 30 Dec 2025 22:16:48 +0000

So I was doing an Advent of Code 2025 challenge the other day, and had an issue where I needed to count all the unique numbers between multiple ranges. It reminded me of some code I'd written previously for a booking system.

The problem was that the ranges overlapped in many cases. Now, looping over all the numbers and using a set() was not feasible, nor performant as the ranges could be in the millions.

The Naïve Approach

unique_values = set()
for start, end in ranges:
    unique_values.update(range(start, end + 1))

For a range of say 1-100_000_000_000 you'd create 1 billion numbers in memory, that's huge! You're also materialising data that doesn't need to exist.

Solution - Merge First, Count Later

Instead of creating every number in memory (expensive), we merge overlapping ranges into fewer, larger ranges, then calculate the count mathematically.

Lets look at a smaller range for the purpose of this tutorial:

Let's say we have the following ranges:

3-5, 
10-14, 
16-20, 
12-18

some of them overlap or touch each other.
10-14 and 12-18 overlap (they share 12, 13, 14)

If merged, they become one range: 10-18. Without merging, you'd count numbers twice or waste memory storing every individual number.

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Sorting the arrays by their start position makes the merging a lot easier - we read from left-to-right on the number line.

sorted_ranges = sorted(fresh_ranges)
# Before: [(3,5), (10,14), (16,20), (12,18)]
# After:  [(3,5), (10,14), (12,18), (16,20)]

How does this help though? When you encounter a new range, you only need to check if it overlaps with the last merged range. There's no need to check all previous ranges. If ranges are sorted, overlaps always happen with the most recent range, saving time and effort checking other ranges.

Sorted number line view:
   3---5      10----14
              12------18
                  16----20

# You can see overlaps flow left-to-right!

Second - Merge the overlapping ranges

merged = []
for start, end in sorted_ranges:
    if merged and start <= merged[-1][1] + 1:
        # Overlaps or touches - merge!
        merged[-1] = (merged[-1][0], max(merged[-1][1], end))
    else:
        # Doesn't overlap - add as new range
        merged.append((start, end))

Why merged and start <= merged[-1][1] + 1?
This condition checks two things:

merged → Is there at least one range already merged?

First iteration: merged = [] → False, so add first range

Later: merged = [(3,5)] → True, check overlap
start <= merged[-1][1] + 1 → Does current range touch/overlap the last merged range?

Lets take a look at some examples:

# Case 1: Adjacent (touching)
Last merged: (10, 14)  # ends at 14
Current:     (15, 20)  # starts at 15
Check: 15 <= 14 + 1? → 15 <= 15? → YES! They touch

# Case 2: Gap between ranges
Last merged: (3, 5)    # ends at 5
Current:     (10, 14)  # starts at 10
Check: 10 <= 5 + 1? → 10 <= 6? → NO! Gap exists

Why + 1?

Ranges for example like (5,10) and (11,15) are adjacent. They shouldn't stay separate (gap at position 10.5). The + 1 is about merging adjacent ranges that touch, not just overlapping ones.

Example:

Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (10, 15) →  10, 11, 12, 13, 14, 15

Number line:
5--6--7--8--9--10--11--12--13--14--15
[======A======][========B========]
              ↑
          They TOUCH at position 9→10

Without +1:
Check: 10 <= 9? → NO ❌
Result: Keep separate [(5,9), (10,15)]
This is WRONG - there is no gap! They should be one range: (5,15)

With +1:
Check: 10 <= 9+1? → 10 <= 10? → YES ✅
Result: Merge to (5, 15)
This is CORRECT!

# Actual Gap
Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (11, 15) →  11, 12, 13, 14, 15

Number line:
5--6--7--8--9--(10)--11--12--13--14--15
[======A======]  GAP  [=======B=======]
              ↑      ↑
          Ends at 9  Starts at 11
          10 is missing!

With +1:
Check: 11 <= 9+1? → 11 <= 10? → NO ✅
Result: Keep separate [(5,9), (11,15)]
This is CORRECT - there's a gap at position 10

Simply, sum each range to get the total number of items within the ranges.

total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Final Code:


# Sort ranges by start position
    sorted_ranges = sorted(fresh_ranges)

    # Merge overlapping ranges
    merged = []
    for start, end in sorted_ranges:
        print(merged)
        if merged and start <= merged[-1][1] + 1:
            # Overlapping or adjacent - merge with last range
            merged[-1] = (merged[-1][0], max(merged[-1][1], end))
        else:
            # No overlap - add new range
            merged.append((start, end))

    # Calculate total count from merged ranges
    total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Real Life Usages:

There are many scenarios in real life where you may need to handle multiple ranges needing merged, or to be counted;

For example:

Appointment Booking Systems:

Meeting A: 9:00 AM - 10:30 AM
Meeting B: 10:15 AM - 11:00 AM  
Meeting C: 2:00 PM - 3:30 PM
Meeting D: 3:30 PM - 5:00 PM

Sorted: [(9:00, 10:30), (10:15, 11:00), (2:00, 3:30), (3:30, 5:00)]

Merged: [(9:00, 11:00), (2:00, 5:00)]
         ↑               ↑
   Meetings A+B overlap  Meetings C+D touch (adjacent)

Free times: Before 9:00, 11:00-2:00, After 5:00

When is the room actually free?

IP Address Blocking

Block: 192.168.1.0 - 192.168.1.50
Block: 192.168.1.45 - 192.168.1.100
Block: 192.168.1.200 - 192.168.1.255

Without merging, check 3 rules for every connection.
With merging -
[(192.168.1.0, 192.168.1.100), (192.168.1.200, 192.168.1.255)]

Only 2 rules to check = Faster firewall!

Maintenance Downtime

Server or Machine scheduled for maintenance:

Maintenance A: Hour 0-5
Maintenance B: Hour 4-8
Maintenance C: Hour 20-24

Merged downtime: [(0, 8), (20, 24)]
Total downtime: 8 + 4 = 12 hours (not 17 if counted individually)

Why This Matters in All Cases:

Avoid double-counting overlapping periods
Optimise checks - fewer ranges to search
Find gaps - available time slots
Accurate reporting - real busy vs. free time
Performance - checking fewer merged ranges vs. many overlapping ones

Conclusion

The above pattern / method is used by multiple companies around the globe, handling calendar invites, database indexing, network traffic analysis and much more.

Go ahead, use the above code to increase your applications performance.

If you want to chat, or reach out don't hesitate to comment below, or drop me a follow on x/twitter.

Spread Operator and Chaining in JS/TS

Grant Riordan — Tue, 30 Sep 2025 13:39:09 +0000

Hey, so I’m sometimes asked how the spread operator works in JS especially when working with chained statements.

Some confuse the ... (spread) operator as applying to the first element of the chain, spreading the variable before applying chained functions.

This isn’t correct; it applies to the result of the chain.

Take this code:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length)
  );
};

Some may think it spreads the sentence variable first then applies the other chained functions, which you would be right in thinking would throw an error.

However, due to the way that JS works the . operator is seen as what's called a primary expression, meaning it takes *precedence * over every other operator.

This would be the same as if you wrote your code like this, wrapping your statement in brackets:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...(sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length))
  );
};

But fortunately for us these extra brackets aren't needed due to the . expression precedence.

So in fact what the code is doing is:

Replace all . in a string.
Split the result on spaces.
Return the length of each word.
Spread the lengths array to Math.max()

Code is read left to right, treating the chain as a single variable / element - so no need to wrap our statement in extra brackets.

Hope this helps 😁 - did you know this?

C# LeetCode 268: Missing Number - (Easy)

Grant Riordan — Thu, 25 Sep 2025 20:46:18 +0000

LeetCode 268: Missing Number

This problem gives you an array of distinct numbers ranging from 0 to n, with one number missing. Your task is to find that missing number.
At first, I misread the instructions — I assumed the highest number would be the array's maximum value, not realizing that n is both the length of the array and the upper bound of the range [0, n]. That realisation changed everything for me.

Solution

To solve this, we can use a well-known mathematical formula known as Gauss's formula. It calculates the sum of the first n natural numbers:

Sum = n * (n + 1) / 2

This works because you can pair numbers in the sequence so that each pair adds up to the same value, take the numbers between 1 and 100:

1 + 100 = 101  
2 + 99  = 101  
3 + 98  = 101  
...

n is multiplied by the number of possible pairings (n + 1). Then as we're doing pairings we need to half this number.

So, if the array had no missing number, its sum would match this formula. But since one number is missing, the actual sum of the array will be less than the expected sum.

Thus, the missing number is simply:
Missing = Expected Sum - Actual Sum

Code

public int MissingNumber(int[] nums)
{
    int n = nums.Length;
    int expectedSum = n * (n + 1) / 2;
    int actualSum = 0;

    foreach (int num in nums)
    {
        actualSum += num;
    }

    return expectedSum - actualSum;
}

Example Walkthrough


var numbers = [0, 3, 1];

# sum of all numbers
0 + 3 + 1 = 4

## all numbers added up using Gauss
# 0 -> 3
n = 3
3 * (3 + 1) / 2 = 6

So we can then subtract 6 (Gauss sum) - 4 (actual sum) = 2

So the missing number would be 2.

LeetCode 8: String to Integer (atoi) - Medium

Grant Riordan — Sun, 21 Sep 2025 20:58:52 +0000

Mastering LeetCode 8: String to Integer (atoi)

A Simple and Efficient Solution

LeetCode's String to Integer (atoi) is a classic medium-difficulty coding problem that challenges you to convert a string representation of a number into an actual integer. While it sounds straightforward, the problem comes with a few twists: you need to handle leading whitespace, account for positive or negative signs, and ensure the result stays within the 32-bit signed integer range.

In this post, I'll walk you through a highly efficient solution that achieves:

0ms runtime (beating 100% of submissions)
41.85MB of memory (better than 50% of submissions)

Understanding the Problem

The goal is to take a string, such as " -42", "4193 with words", or "+123", and convert it into an integer, like -42, 4193, or 123. Here are the key requirements

Ignore leading whitespace: Skip any spaces at the start of the string.
Handle signs: Recognise + or - to determine if the number is positive or negative.
Stop at invalid characters: If you encounter a non-digit (other than the initial sign), stop processing.
Respect 32-bit integer bounds: If the result exceeds the 32-bit signed integer range (-2^31 to 2^31 - 1), return the appropriate boundary value (-2^31 or 2^31 - 1).
Default to 0: If the string is empty or contains no valid digits, return 0.

My Approach: Simple and Fast

I designed a solution that prioritises efficiency by working directly with the string's characters and using indexing to avoid unnecessary operations. Here's the step-by-step approach:

Check for Empty Input: If the string is null or empty, return 0.
Skip Whitespace: Loop through the string to bypass leading spaces, avoiding methods like .Trim() to reduce overhead.
Handle the Sign: Assume the number is positive by default (sign = 1). If a + or - is found, update the sign variable and move to the next character.
Build the Number: Process each digit character, converting it to its numeric value and building the result incrementally. Stop if a non-digit is encountered.
Check Bounds: As the number is built, ensure it stays within the 32-bit integer limits, clamping to int.MaxValue or int.MinValue if necessary.
Apply the Sign: Multiply the result by the sign to get the correct positive or negative value.

This approach is clean, avoids heavy string operations, and handles all edge cases efficiently.

The Code

class Solution
{
    public int MyAtoi(string s)
    {
        // Handle null or empty string
        if (string.IsNullOrEmpty(s)) return 0;

        int idx = 0, end = s.Length;

        // Skip leading whitespace
        while (idx < end && s[idx] == ' ') idx++;
        if (idx == end) return 0; // Return 0 if only whitespace

        // Check for sign
        int sign = 1; // Default to positive
        if (s[idx] == '+' || s[idx] == '-')
        {
            sign = (s[idx] == '-') ? -1 : 1; // Set sign based on + or -
            idx++;
        }

        int result = 0;
        // Process digits
        while (idx < end && char.IsDigit(s[idx]))
        {
            // Convert character to digit (e.g., '5' -> 5)
            int digit = s[idx] - '0';

            // Check for overflow before adding digit
            if (result > (int.MaxValue - digit) / 10)
            {
                return sign == 1 ? int.MaxValue : int.MinValue;
            }

            // Build number: multiply by 10 and add new digit
            result = result * 10 + digit;
            idx++;
        }

        // Apply sign to get final positive or negative result
        return result * sign;
    }
}

How It Works

Whitespace Handling: The while (idx < end && s[idx] == ' ') loop skips leading spaces. If the string contains only whitespace, we return 0.

Sign Detection: We default to sign = 1 (positive). If a + or - is found, we set sign to 1 or -1 and advance the index (so the index will be at the first character).

Number Building: For each digit, we convert the character to its numeric value (e.g., '5' - '0' = 5). We build the number by multiplying the current result by 10 and adding the new digit (e.g., for "123", we do 0*10 + 1 = 1, 1*10 + 2 = 12, 12*10 + 3 = 123).

Overflow Check: Before adding a digit, we check if result * 10 + digit would exceed int.MaxValue. If so, we return int.MaxValue or int.MinValue based on the sign.

Final Sign Application: Multiplying result by sign ensures the correct positive or negative output (e.g., 123 * -1 = -123).

Hope this has helped, as always give me a follow, or drop me a line on twitter/x

LeetCode 206: Reverse Linked List - (Easy)

Grant Riordan — Tue, 16 Sep 2025 13:37:28 +0000

Given the head of a singly linked list, reverse the list, and return the reversed list.

Approach & Solution

We reverse a linked list by keeping track of two pointers: prev (the previous node) and curr (the current node). At each step, we:

Save the next node so we don’t lose track of the list.
Reverse the current node’s pointer to point to prev.
Move prev forward to curr.
Move curr forward to the saved next node.

We continue until curr is null, meaning we’ve processed all nodes. At that point, prev will be the new head of the reversed list.

Code

ListNode ReverseList(ListNode head)
{
ListNode prev = null;
ListNode curr = head;

while (curr != null)
{
    ListNode nextNode = curr.next;
    curr.next = prev;
    prev = curr;
    curr = nextNode;
}

return prev; // new head

}

Extension Members: My New Favourite Feature in C# 14

Grant Riordan — Fri, 12 Sep 2025 18:49:31 +0000

The release candidate of .Net10 was released on the 9th September [2025], which comes with C# 14, and with that comes one of my favourite features, Extension Members

The Concept

The new extension keyword defines an extension scope; a block where you declare which type your extension methods apply to. All methods inside that scope automatically extend the specified type.

Before and After

Current Implementation

So up until C# 14 you would declare an extension method like this:

public static class StringExtensions
{
    public static string ToTitleCase(this string input) =>
         CultureInfo.CurrentCulture.TextInfo.ToTitleCase(input.ToLower());
}

It can be cumbersome, and to some junior developers it may not be obvious that the method is an extension method. You would have to know that static + this = extension.

The New Way

Firstly you declare your extensions scope using the new extension keyword:

public static class StringExtensions
{
   extension(string text)
   {
      // extension methods go here
   }
}

This replaces the (this string text) syntax, now all methods within this block apply to this type. The new syntax makes declaring all your extensions for this type much cleaner and tidier.

Let's add some basic extensions to show you the concepts:

public static class StringExtensions
{

    extension(string text)
    {
        public string ToTitleCase() =>
            CultureInfo.CurrentCulture.TextInfo.ToTitleCase(text.ToLower());

        public bool IsPalindrome() =>
            text.SequenceEqual(text.Reverse());
    }

}

The examples above show just how easy it is to now declare multiple extension methods on the same type, because we can just use the scoped variable text , rather than having to redefine it each time with this.

Shorter Method Declarations:

// before
public static class DateTimeExtensions
{
    public static bool IsWeekend(this DateTime date) =>
        date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

//after
public static class DateTimeExtensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() =>
            date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;

        public bool IsBusinessHours() =>
            date.Hour is >= 9 and < 17 && !date.IsWeekend();
    }
}

Extensions Can Easily Be Grouped

Before C# 14, you might see a single Helpers class like this:

public static class Extensions
{
    // for DateTime
    public static bool IsWeekend(this DateTime date) { … }

    // for collections
    public static bool HasDuplicates<T>(this IEnumerable<T> items) { … }

    // for strings
    public static string ToTitleCase(this string text) { … }

    // and so on...
}

The problem with this approach:

Hard to maintain– Over time, these Helpers classes can balloon to 500–1,000+ lines of mixed methods, making it difficult for developers to find what they need. – One file can contain extensions for multiple unrelated types.

Before C# 14	After C# 14
Helpers.cs (mixed types)	Extensions.cs (type-scoped)
- DateTime extensions	- extension(DateTime date) { … }
- IEnumerable extensions	- extension(IEnumerable items) { … }
- string extensions	- extension(string text) { … }
- Random other methods	… neatly grouped per type

Let's take a look how the code may look with the new groupings:

public static class Extensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() {...}

        public bool IsBankHoliday() {...}

        public bool FormatIsoDate() {...}
    }

    extension(IEnumerable<T> items)
    {
        public bool HasDuplicates() {...}
    }

    extension(string text)
    {
        public string ToTitleCase() {...}
    }
}

That means:

*Natural grouping by type *– all string extensions must sit inside the extension(string) scope, all DateTime ones inside extension(DateTime).

Prevents mixing unrelated stuff– you literally cannot write a string extension in the DateTime scope. The compiler enforces it.

Cleaner discoverability– IDEs and developers now know exactly where to look. If you collapse your editor, you’ll see one extension(string) block, one extension(DateTime) block, instead of a 500+ line god like class of random extensions.

Before, people dumped everything into Helpers.cs.

Now, even if your team of developers decides to keep a single file called Extensions.cs, the syntax itself enforces organisation by type, so it’s much less likely to create a “misc soup” of extensions scattered around the file.

We Now Have Extension Properties !

New in C#14 we no longer just have to have extension methods, we can now utilise extension properties. Meaning without huge refactors, or updating multiple places you can easily add Extension properties, to compute results.

For example:

extension<T>(IEnumerable<T> source)
{
    public bool IsNullOrEmpty => source == null || !source.Any();
}

You now have a IsNullOrEmpty property which will be attached to every IEnumerable type within your code base.

So you can do things like:

    List<string> names = ["Grant Green", "Roger Red", "Bianca Blue"];

    // Before (method style)
    if (names.IsNullOrEmpty())
    {
        Console.WriteLine("No names found!");
    }

    // After C# 14 (property style)
    if (names.IsNullOrEmpty)
    {
        Console.WriteLine("No names found!");
    }

I think you'll agree using a property instead of a method makes the code read like it's part of the type itself. It's cleaner, easier to read, and removes the mental overhead of remembering parentheses for simple checks.

Final thoughts

C# 14’s extension members are a small language change with a big impact!

They enforce better organisation by type, reducing the mess of “miscellaneous helpers” spread across static classes.

Extension properties make your APIs feel more natural, allowing boolean checks and computed values to read like first-class members of the type.

Overall, your code becomes cleaner, more discoverable, and easier for teams to maintain.

While the compiler doesn’t stop you from scattering extensions across multiple classes, using a consistent type-scoped approach helps keep your codebase tidy and readable.

In short: if you frequently write helper methods or utilities, C# 14 extension members are worth adopting — they make your codebase feel more structured and your extensions feel like they belong.

Which types do you most often extend in your projects? I’d love to hear your thoughts in the comments or drop me a follow on twitter/x to hear when I post more articles like this on DevTo and FreeCodeCamp.

C# LeetCode 1792: Maximum Average Pass Ratio - (Medium)

Grant Riordan — Thu, 04 Sep 2025 18:14:59 +0000

LeetCode 1792: Maximum Average Pass Ratio - (Medium Difficulty)

Intuition

Needed a way to determine which class would yield the best return on adding the extra students.

Best way to track this in my mind would be tracking a Priority, so a PriorityQueue would be ideal for this scenario. A PriorityQueue lets us always select the class with the current highest gain efficiently in O(log n) time per operation.

Approach

Populate the queue with initial values and the gain in pass ratio from adding one student to each class.
For each student, take the class with the highest gain from adding one more passing student.
Loop over the priority queue adding up all the ratios and divide by number of classes to get the average ratio.

Example

Let's say you have two classes:

Class	Pass	Total	Initial Gain from 1 Student
A	1	2	0.1667
B	3	5	0.0667

First assignment:

Class A has higher gain → gets 1 student → now A = [2,3]

Next round:

New gain for A:
(3/4) - (2/3) = 0.75 - 0.6667 = 0.0833

Class B still has gain:
(4/6) - (3/5) = 0.6667 - 0.6 = 0.0667

→ A still has higher gain (0.0833 vs 0.0667), so gets another student.

Now A = [3,4]

Third round:

Gain for A now:
(4/5) - (3/4) = 0.8 - 0.75 = 0.05

Class B gain is still 0.0667

✅ Now B has higher gain — it gets the next student.

When solving this problem, you might wonder:

“Aren’t we already adding one extra student when we calculate the initial gain? Then adding more? Isn’t that overcounting?”

The answer is no — and here’s why.

The iniital gain is just a prediction. When we calculate the gain for a class:

Gain(pass, total) = Ratio(pass + 1, total + 1) - Ratio(pass, total)

We're not actually adding a student.
We're just asking a "what if" question:

“If I gave one extra passing student to this class, how much would its pass ratio improve?”

This helps us prioritize which class would benefit the most if it were chosen next.

Code

public class Solution {
    public double MaxAverageRatio(int[][] classes, int extraStudents)
    {
        var pq = new PriorityQueue<(int pass, int total), double>(
            Comparer<double>.Create((a, b) => b.CompareTo(a))
        );

        // Populate the queue with initial values
        foreach (var cls in classes)
        {
            var pass = cls[0];
            var total = cls[1];
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // Distribute extra students
        for (var i = 0; i < extraStudents; i++)
        {
            var (pass, total) = pq.Dequeue();
            pass++;
            total++;
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // After distribution, calculate final average
        double sum = 0;
        while (pq.Count > 0)
        {
            var (pass, total) = pq.Dequeue();
            sum += CalculateRatio(pass, total);
        }

        return sum / classes.Length;
    }

    double CalculateRatio(int pass, int total)
    {
        return (double)pass / total;
    }

    double Gain(int pass, int total)
    {
        var current = CalculateRatio(pass, total);
        var after = CalculateRatio(pass + 1, total + 1);
        return after - current;
    }
}

LeetCode 168: Excel Sheet Column Title (Easy)

Grant Riordan — Sat, 30 Aug 2025 17:00:11 +0000

Approach

This problem is essentially a base-26 conversion, where the "digits" are the 26 letters of the alphabet (A–Z).

Like any base conversion, we process the least significant digit first — meaning we figure out the last letter of the result before the first.

Use the modulo operator (% 26) to find the remainder, which tells us the current character.
Insert each character at the front of the string (or reverse later), since we’re building the result from right → left.
After each step, divide columnNumber by 26 to move on to the next "digit."
Important: decrement columnNumber at the start of each loop (columnNumber--) because Excel columns are 1-based, while our alphabet mapping is 0-based.

Example Flow (columnNumber = 28)

Iteration 1

Input: 28
columnNumber-- → 27
Remainder: 27 % 26 = 1
Character: 'A' + 1 = 'B'
Result: "B"
Update columnNumber: 27 / 26 = 1

Iteration 2

columnNumber-- → 0
Remainder: 0 % 26 = 0
Character: 'A' + 0 = 'A'
Result: "AB"
Update columnNumber: 0 / 26 = 0 → stop

✅ Final result = "AB"

We can verify manually:

27 = 1 full cycle (A → Z) + 2 more columns (AA, AB).

Code


csharp
public class Solution {
    public string ConvertToTitle(int columnNumber) {
        var result = new StringBuilder();

        while (columnNumber > 0) {
            columnNumber--; // shift into 0-based
            int remainder = columnNumber % 26;
            result.Insert(0, (char)('A' + remainder));
            columnNumber /= 26;
        }

        return result.ToString();
    }
}

Stop Throwing Exceptions: The ServiceResult Pattern for Clean API

Grant Riordan — Fri, 29 Aug 2025 13:56:37 +0000

Error handling in APIs can get pretty messy, right?

Whether it's throwing exceptions for "expected" situations like “User not found,” or dealing with ambiguous null values, traditional error handling approaches often leave us with more questions than answers. But don't worry—there's a better way!

Imagine you're a waiter taking orders: if a customer orders a dish that’s not available, you don’t throw a tantrum or drop everything in the kitchen (throw Exception). Instead, you let them know it’s not available and suggest something else. Same idea applies to your API!

In this post, I’ll walk you through how the Discriminated Union pattern (using a ServiceResult type) can simplify your error handling, making your code more predictable and easy to maintain.

In simple terms, a Discriminated Union is a way to define a type that can be one of several distinct types, each with its own properties.

Why Traditional Error Handling Doesn’t Cut It
The ServiceResult Pattern
Usage Example
Benefits of This Approach
Real-World Error Handling
Separation of Concerns
Flow of Code Example
Caveats and Considerations
Final Thoughts

Why Traditional Error Handling Doesn’t Cut It

When building APIs or services, one of the first design decisions you’ll face is how to represent the outcome of an operation.

Exceptions aren’t always exceptional (e.g. “User not found” is normal, not an error).
Nulls are ambiguous (is it missing, or did something go wrong?).

Wrapping results in a ServiceResult<T> gives clarity: every call is either a success or a failure.

The ServiceResult Pattern

At its core, every service call has two possible outcomes.

It succeeds, giving you the entity / object you wanted.
It fails, giving you structured error details.

In functional programming, this is often called a Discriminated Union (a type with a fixed set of possibilities). You may be more familiar with union types if using for example Typescript.
In C# these don't exist, however, we can express this cleanly with records:

Is is my interpretation is below:

public abstract record ServiceResult<TEntity>
{
    public sealed record Success(TEntity Entity)
        : ServiceResult<TEntity>;

    public sealed record Failure(string[] Errors, ErrorType ErrorType)
        : ServiceResult<TEntity>;

    public static ServiceResult<TEntity> FromSuccess(TEntity entity)
        => new Success(entity);

    public static ServiceResult<TEntity> FromFailure(string[] errors, ErrorType errorType)
        => new Failure(errors, errorType);
}

Below is the implementation of the ErrorType enum:

public enum ErrorType
{
    Validation,
    NotFound,
    Conflict,
    Database,
    Unexpected
}

Here’s what’s happening:

Success → wraps the entity so you know the operation worked.

Failure → captures one or more error messages and an error type (NotFound, Conflict, etc.).

Instead of manually creating new instances of Success or Failure, the factory methods FromSuccess and FromFailure let you do it with one simple line of code. It's like a shortcut to avoid any mistakes or extra boilerplate.

This gives you a predictable, strongly-typed contract. Whenever you call a service, you must deal with either Success or Failure.

Here is an example of how ServiceResult and ErrorTypes could be used:

Case	What you get	Why it’s useful
Success	`Entity`	Normal outcome, strongly typed result
Failure	`Errors[]`, `ErrorType`	Clear reason for failure, caller knows what broke
Validation Failure	`Errors[]`, `Validation`	Communicates bad input without exceptions
Not Found	`Errors[]`, `NotFound`	Expresses absence cleanly (instead of null/404)
Conflict	`Errors[]`, `Conflict`	Useful for concurrency/duplicate key scenarios
Database/Server	`Errors[]`, `Database`	Lets you bubble up infra issues in a controlled way
Unexpected Exception	(thrown, not returned)	Reserved for truly exceptional conditions

If the operation fails, you get one or more error messages and an ErrorType enum.

This gives the caller enough context to decide what to do next — maybe return a 404, maybe log an error, maybe retry.

Usage Example

Now that we’ve got our ServiceResult type, let’s see what it looks like in practice.

Imagine you’re building a movie service, and you need to update a movie. Instead of throwing an exception when the movie isn’t found, you return a Failure result:

// Service layer - MovieService.UpdateAsync()

public async Task<ServiceResult<Movie>> UpdateAsync(UpdateMovieRequest req)
{
    var movie = await repository.GetByIdAsync(req.Id);

    if (movie is null)
        return ServiceResult<Movie>.FromFailure(
            new[] { "Movie not found" },
            ErrorType.NotFound
        );

    movie.Title = req.Title;
    await repository.SaveChangesAsync();

    return ServiceResult<Movie>.FromSuccess(movie);
}

A few things to notice here:

No exceptions for expected outcomes (Movie not found is normal, not exceptional).
Consistent shape: every exit path returns a ServiceResult.
Flexible: you can add richer error context over time (Validation, Conflict, etc.).

Then in your API handler (controller/endpoint), you can use pattern matching to decide what to return:

var result = await movieService.UpdateAsync(request);

switch (result)
{
    case ServiceResult<Movie>.Success success:
        return Ok(success.Entity);

    case ServiceResult<Movie>.Failure failure:
        return StatusCode(
            MapErrorTypeToStatusCode(failure.ErrorType),
            failure.Errors
        );

    default:
        throw new InvalidOperationException("Unexpected result type");
}

Now the controller stays thin — no exception handling logic, no try/catch bloat — just clear translation of service outcomes into HTTP responses.

Benefits of This Approach

Predictable: Callers must handle both success and failure, making bugs less likely.

Expressive: You can return multiple errors, not just a single exception message.

Performant: You avoid throwing/catching exceptions for normal control flow.

Modern C#: Uses records and pattern matching — concise, readable, and type-safe.

Real-World Error Handling

So far we’ve only looked at simple success/failure outcomes, but real-world services often hit database or infrastructure errors. Traditionally, you’d wrap service logic in try/catch and bubble exceptions up to the controller — which makes your API code messy and inconsistent.

With ServiceResult<TEntity>, we can catch exceptions inside the service and still return a clean, predictable result.

Here’s an example for deleting a movie:

public async Task<ServiceResult<bool>> DeleteAsync(int id)
{
    var movieResult = await GetByIdAsync(id);

    if (movieResult is ServiceResult<Movie>.Failure failure)
    {
        return new ServiceResult<bool>.Failure(failure.Errors, failure.ErrorType);
    }

    try
    {
        await repository.DeleteAsync(id);
        await repository.SaveChangesAsync();
        return new ServiceResult<bool>.Success(true);
    }
    catch (DbUpdateException ex)
    {
        logger.LogError(ex, "Database error while deleting movie {MovieId}", id);

        return new ServiceResult<bool>.Failure(
            new[] { $"Failed to delete movie: {ex.Message}" },
            ErrorType.Database
        );
    }
}

Notice what’s happening here:

Expected errors (movie not found) are modeled as failures with ErrorType.NotFound.

Unexpected errors (like DbUpdateException) are caught and translated into ErrorType.Database.

The calling code doesn’t need to care whether it was a validation error, missing data, or a DB issue — it just sees Failure and can respond appropriately.

Here’s what the API handler looks like:

public override async Task HandleAsync(DeleteMovieRequest req, CancellationToken ct)
{
    var result = await movieService.DeleteAsync(req.Id);

    switch (result)
    {
        case ServiceResult<bool>.Failure failedResult:
            foreach (var error in failedResult.Errors)
            {
                AddError(error);
            }

            await Send.ErrorsAsync(MapErrorTypeToStatusCode(failedResult.ErrorType), ct);
            return;

        case ServiceResult<bool>.Success:
            logger.LogInformation("Deleted movie with ID: {MovieId}", req.Id);
            await Send.OkAsync(new DeleteMovieResponse(true), ct);
            return;
    }
}

No try/catch in the controller, no exception mapping logic scattered around.
All failure handling is centralized in the service, while the API handler simply translates ErrorType → HTTP status code.

Separation of Concerns:

Encourages separation of concerns as services don’t need to know about HTTP or status codes.

Endpoints/controllers can translate ServiceResult.Failure → 400/404/500 as appropriate.

Example:

if (result is ServiceResult<Movie>.Failure failure)
{
    var status = failure.ErrorType switch
    {
        ErrorType.Validation => 400,
        ErrorType.NotFound => 404,
        ErrorType.Conflict => 409,
        _ => 500
    };
    await Send.ErrorsAsync(status, ct, failure.Errors);
}

It’s a much cleaner alternative than handling multiple custom exception types in your API handler.

Flow of Code Example:

                   +----------------------+
                   |   Service Call       |
                   +----------------------+
                            |
                            v
             +------------------------------+
             |  Was the operation a success?|
             +------------------------------+
              /                        \
             /                          \
            v                            v
+-------------------+         +--------------------------+
|   Success         |         |   Failure                |
|-------------------|         |--------------------------|
|   Return Entity   |         |   Error Type (e.g.       |
|   (TEntity)       |         |   Validation, NotFound,  |
+-------------------+         |   Conflict, Database,    |
                              |   Unexpected)            |
                              +--------------------------+
                                       |
                                       v
                           +--------------------------+
                           | Return Error Details     |
                           | (Errors[], ErrorType)    |
                           +--------------------------+

Caveats and Considerations

While the ServiceResult pattern is straightforward and provides clarity, it's important to be mindful of the context in which it's applied. In smaller applications with very simple error handling needs, this pattern might feel like overkill, but as your system grows and complexity increases, the benefits far outweigh the initial overhead.

One potential challenge is ensuring that your ErrorType enum is comprehensive enough to cover all potential failure scenarios. If you miss a common error type, the pattern might lose some of its expressiveness. However, with proper design and planning, this pattern keeps error handling clean, maintainable, and easy to extend as your app evolves. Ultimately, it encourages good separation of concerns and helps avoid clutter in your API handlers.

The key takeaway is that it offers a solid, scalable foundation for error handling, and once in place, it keeps your codebase more predictable and robust in the long run.

Final Thoughts

For expected outcomes (like a user not found or bad input), use ServiceResult<T> to return a structured Failure result. This is part of your normal control flow.

For truly exceptional, unexpected issues (like a database connection failure), let exceptions be thrown. This prevents messy try/catch blocks in your service and API layers.

Centralise logic; by catching infrastructure exceptions (like DbUpdateException) inside your service and converting them to a ServiceResult.Failure, you keep your API handlers clean and focused on translating outcomes into HTTP responses."

What do you think of this pattern? Do you use a similar approach, or do you prefer a different method for handling API errors? Share your thoughts in the comments!

DEV Community: Grant Riordan

Stop Writing Raw Python - Let C Handle It

How Python Actually Runs

The C-Backed Library Trick

Vectorisation: The Real Unlock

Where Does JavaScript Sit?

A Quick Comparison

What This Changes About How I Write Python

The Bigger Picture

Stop Writing Python — Let C Do It

How Python Actually Runs

The C-Backed Library Trick

Vectorisation: The Real Unlock

Where Does JavaScript Sit?

A Quick Comparison

What This Changes About How I Write Python

The Bigger Picture

AI Can Not Be Left Unsupervised

Other Damaging Cases

Final Note

Using Python To Merge Array of Ranges

The Naïve Approach

Solution - Merge First, Count Later

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Second - Merge the overlapping ranges

Lets take a look at some examples:

Final Code:

Real Life Usages:

Appointment Booking Systems:

IP Address Blocking

Maintenance Downtime

Why This Matters in All Cases:

Conclusion

Spread Operator and Chaining in JS/TS

C# LeetCode 268: Missing Number - (Easy)

Solution

Code

Example Walkthrough

LeetCode 8: String to Integer (atoi) - Medium

A Simple and Efficient Solution

Understanding the Problem

My Approach: Simple and Fast

The Code

How It Works

LeetCode 206: Reverse Linked List - (Easy)

Approach & Solution

Code

Extension Members: My New Favourite Feature in C# 14

The Concept

Before and After

Current Implementation

The New Way

Shorter Method Declarations:

Extensions Can Easily Be Grouped

We Now Have Extension Properties !

Final thoughts

C# LeetCode 1792: Maximum Average Pass Ratio - (Medium)

Intuition

Approach

Example

Code

LeetCode 168: Excel Sheet Column Title (Easy)

Approach

Example Flow (columnNumber = 28)

Code

Stop Throwing Exceptions: The ServiceResult Pattern for Clean API

Table of Contents

Why Traditional Error Handling Doesn’t Cut It

The ServiceResult Pattern

Usage Example

Benefits of This Approach

Real-World Error Handling

Separation of Concerns:

Flow of Code Example:

Caveats and Considerations

Final Thoughts