#Why this tiny project is still useful

This project looks small from the outside. It takes a string, a target character, a replacement character, and an occurrence number, then returns an updated string.

Simple enough.

But it is exactly the kind of coding task that exposes how you think about edge cases, validation, and testing discipline. That is why I kept it in my portfolio.

#The requirement in plain terms

The core method behaves like this:

Replace(string word, char replace, char replaceWith, int occurrence)

The method scans the input, finds matching character positions, and replaces characters based on occurrence logic.

Examples from the project:

Input: ("apple", 'p', 'b', 1) -> output: "abble"
Input: ("appppple", 'p', 'b', 2) -> output: "apbpbpble"

The second example is where most people stop and rethink. It confirms the method is not just "replace first match" but "replace by occurrence pattern." That distinction matters.

#Input validation and custom exceptions

I added two custom exceptions in this project:

myIllegalParamException for null string input
myNegativeParamException for invalid negative occurrence values

This was intentional.

I wanted to practice writing code that fails loudly and clearly when the input contract is broken. Silent failure in utility methods always comes back as debugging pain later.

#Implementation approach

The method takes these steps:

Validate input (word not null, occurrence not negative).
Convert the string to a char array.
Collect indexes of all matching characters.
Apply replacements according to occurrence logic.
Return a new string from the updated char array.

In the implementation, I used List<int> to store match indexes before mutation. That made the replacement pass easier to reason about.

Could this be done with LINQ or regex? Sure. But for this assignment, explicit loops were better because they made behavior obvious and testable.

#Unit testing was the important part

The repository includes a unit test project with test cases for both normal behavior and exceptions.

The tests cover:

First occurrence replacement
Second occurrence pattern replacement
Null input exception
Negative occurrence exception

This part was the main value of the project for me. Writing the method was quick. Proving its behavior across edge cases took more careful thought.

That is where I improved.

#Common mistakes this project helps avoid

If you are learning C# string processing, this exercise highlights a few traps:

Confusing "Nth occurrence" with "every Nth occurrence"
Forgetting null input checks
Mutating strings incorrectly (strings are immutable in C#)
Skipping tests because the method "looks obvious"

I have made each of these mistakes before. This project helped clean that up.

#What I would improve today

If I revisited this now, I would:

Rename exceptions to standard .NET naming (IllegalParamException -> clearer domain naming)
Document exact expected behavior for occurrence = 0 in method docs
Add parameterized tests for broader coverage
Add benchmarks for long-string performance scenarios
Package it as a reusable helper library with XML docs

I would also make the replacement semantics explicit in the README with a short truth table so there is no ambiguity.

#Why this belongs in a portfolio

A lot of portfolio projects are flashy but hide code quality details.

This one is the opposite. It is small, readable, and test-oriented. It shows that I can take a narrow requirement, handle invalid inputs, and verify behavior with tests.

For backend and systems work, that mindset is more important than visual complexity.

#SEO relevance

If you are searching for a C# string replacement by occurrence example, or for a C# utility method with custom exceptions and unit tests, this repository is a practical reference.

It is especially useful for students preparing for technical interviews where string manipulation and defensive programming come up often.

#Repository

You can inspect the full implementation and test project here:

GitHub repository