Operators are the symbols that combine values into new values. Adding prices, comparing stock counts, checking whether a customer qualifies for free shipping, all of it routes through a small set of operators with well-defined rules. This chapter walks through every operator category in C#, the gotchas that trip up newcomers (integer division, floating-point equality, overflow), and the precedence rules that decide which operation runs first when you mix them.

The five basic arithmetic operators are the ones you'd expect from a calculator, with one twist around division that catches people off guard.

Here's a small program that uses each one to build a cart total:

Nothing surprising. The values flow through the operators the way you'd read them out loud.

Integer Division vs Floating-Point Division

This is the twist. The / operator looks the same no matter what types you give it, but the result depends on those types. If both operands are integers, C# does integer division and throws away the remainder. If at least one operand is a floating-point or decimal type, you get a real quotient.

The first division returns 3, not 3.5. The .5 doesn't round, it gets truncated. The compiler doesn't warn you about this because it's legal C#, just not always what you wanted. If you need a real quotient from two integers, cast at least one of them: (double)totalItems / 2.

Dividing an integer by zero throws DivideByZeroException at runtime. Dividing a double or float by zero doesn't throw, it returns double.PositiveInfinity, double.NegativeInfinity, or double.NaN depending on the signs. decimal division by zero throws like integers do.

The Modulo Operator

% returns the remainder after division. It shows up more often than people expect: checking whether a number is even (n % 2 == 0), rotating through a fixed set of items (index % count), or wrapping cart sizes into pack sizes.

For negative numbers, C#'s % follows the sign of the dividend, so -7 % 3 is -1, not 2. That matters when you're using it to wrap around an index and the input could be negative.

Unary Plus and Minus

+ and - also work as unary operators on a single value. Unary - negates, unary + does nothing useful and is mostly there for symmetry.

Increment and Decrement

++ and -- add or subtract one from a variable. They come in two flavors: prefix (++count) and postfix (count++). Both change the variable the same way. The difference is what the expression evaluates to.

In standalone statements like count++;, the prefix-vs-postfix distinction doesn't matter, you can use either. The difference only shows up when you use the result inside a larger expression. Mixing increments into complex expressions makes code harder to read. The clean style in modern C# is to put count++; on its own line.

The plain = assigns the right side to the left. Every other assignment operator is shorthand for "do this operation, then assign the result back."

All the compound assignments work the same way:

The ??= operator is the null-coalescing assignment (C# 8). It assigns y to x only when x is currently null.

The second ??= does nothing because promoCode is no longer null.

Comparison operators return bool. They're the building blocks of if conditions, while loops, and any logic that branches.

A small example that checks free shipping eligibility:

Value vs Reference Equality

For value types like int, double, decimal, and bool, == compares the actual values. Two int variables that both hold 5 are equal. Straightforward.

For reference types, == by default compares references, not contents. Two different Cart objects with identical items are not == to each other. They live at different addresses on the heap.

string is the well-known exception. Even though string is a reference type, the language overloads == to compare characters, so "hello" == "hello" returns true as you'd expect. We'll go deep on reference equality, value equality, and Equals versus == in the section on classes and objects.

Floating-Point Comparison Pitfall

Comparing floating-point numbers with == is one of the classic traps. Numbers like 0.1 and 0.2 can't be represented exactly in binary double, so arithmetic on them gives results that look right when you print them but aren't bit-for-bit equal to the "obvious" answer.

The fix is to compare within a small tolerance, often called epsilon:

For money, sidestep the whole problem. Use decimal instead of double. decimal represents base-10 fractions exactly, so 0.1m + 0.2m == 0.3m returns true.

Logical operators combine bool values. There are three:

Short-Circuit Evaluation

&& and || are short-circuit operators. They evaluate the right side only when they have to.

This isn't just an optimization. It changes what your code can safely do, because the right side might be expensive, or might throw on inputs that the left side just ruled out.

The diagram shows the decision. With &&, a false left side ends the evaluation immediately. With ||, a true left side ends it immediately. Otherwise the runtime keeps going and evaluates the right side.

A practical example: null-guarding before accessing a property.

If && evaluated both sides eagerly, couponCode.Length would throw NullReferenceException whenever couponCode was null. Short-circuiting makes the pattern safe: the left check rules out null, so the right side never runs in that case.

C# also has non-short-circuit versions, & and |, which always evaluate both sides. On bool values these are rarely useful and easy to misuse. Their main job is bitwise operations on integers.

Bitwise operators work on the individual bits of an integer. They show up most often when you're packing multiple boolean flags into a single integer (a "bitmask"), which keeps storage tight and lets you combine flags with one operation.

The >>> operator was added in C# 11. The plain >> operator preserves the sign bit when shifting signed integers right, which can give surprising results on negative numbers. >>> always fills the top bits with zero. For unsigned types like uint or byte, >> and >>> behave the same.

A common e-commerce use case is order status flags. You can represent a set of statuses as bits in a single int:

The [Flags] attribute tells the runtime to format combined values as a comma-separated list of names. Combining flags uses |, checking a flag uses &, clearing a flag uses & ~.

You don't need bitwise operators for everyday business logic. Reach for them when you have a small fixed set of independent yes/no states and care about compact storage, or when you're working with low-level data like file permissions, network protocol fields, or hardware registers.

Earlier chapters introduced the null operators. Here's a quick reference. The full coverage lives in the chapter on nullability.

These operators are the modern, concise way to deal with values that might be null. Mastering them keeps your code free of long if (x != null) chains.

C# has two operators for asking and answering "what type is this object?" The deep coverage lives in the section on pattern matching. Here's the preview.

is returns true if a value matches a type or pattern.

The is string productName pattern does two things at once: it checks that item is a string, and if so, declares productName of type string already cast and ready to use.

as attempts a cast. If the value is the requested type, you get it. If not, you get null instead of an exception.

as only works with reference types and nullable value types. For value types like plain int and decimal, use pattern matching with is or an explicit cast inside a try block.

The ?: operator picks one of two values based on a condition. The form is condition ? valueIfTrue : valueIfFalse. It's the only ternary operator in C#, which is why people just call it "the ternary."

Ternaries shine for short either-or assignments. They're also expression-friendly, so you can use them inside string interpolations or method calls without an extra if:

Target-Typed Conditional (C# 9)

Before C# 9, the two branches of a ternary had to have a common type the compiler could resolve. This caused friction when you had types that didn't share an obvious base.

That's the gist. You won't notice it day to day, but it explains why some old patterns suddenly compile in newer projects.

When Not to Use Ternaries

Nested ternaries get unreadable quickly. This is the kind of thing that looks clever and then traps the next person reading the code:

When you have more than two cases, prefer an if/else if chain or a switch expression. The same logic with switch:

Cleaner, and the cases are listed top to bottom in the order they're checked.

C# 8 added two small operators that make slicing collections and strings easier.

Ranges work on arrays, strings, Span<T>, and List<T>. They make a lot of "give me the last N items" or "skip the first one" code read like a sentence.

Integer arithmetic in C# doesn't check for overflow by default. If you add 1 to int.MaxValue, you don't get an exception, you get int.MinValue. The bits roll over the way two's-complement arithmetic does on the underlying hardware.

For money or counters where overflow is a real bug, opt into checked arithmetic. The checked keyword forces overflow checks, and the runtime throws OverflowException if the result doesn't fit.

You can also wrap a block:

The mirror image is unchecked, which forces wraparound behavior even if the surrounding context is checked. You'll mostly use it in performance-sensitive numeric code where wraparound is intentional, like hashing.

The default mode (checked or unchecked) is a project-level setting. The dotnet new template defaults to unchecked for runtime arithmetic but checked for constant expressions, so int x = int.MaxValue + 1; fails to compile but the same expression at runtime silently wraps.

When you mix operators in one expression, precedence decides the order. Higher precedence runs first. Operators with the same precedence are grouped by associativity, which for almost all operators is left-to-right.

You don't need to memorize the whole table. Two practical takeaways cover most cases:

When the expression isn't obvious, add parentheses. Parentheses cost nothing and remove ambiguity for the next person reading the code.

All three lines compute the same value. The third one is the easiest to read because the parentheses make the order obvious without changing the math.