
<Image src="exit.jpg" alt="black and green led light" />

Today, while wrestling with some code, I caught myself smiling at something small but powerful. I was deep in a function
that was starting to look like a staircase of if statements. Halfway through, I stopped and thought: _why am I dragging
all these checks down the page when I could just step out early_?

That’s when it clicked—again 🥳. Early return (or guard clauses, if you like fancy names) isn’t just a coding pattern;
it’s a way of freeing your own brain. You handle the simplest, most obvious stuff first and politely bow out of the
function. Then the rest of the logic can flow without carrying the weight of those initial conditions.

```javascript
function processUser(user) {
  if (!user) return;          // nothing to process
  if (!user.isActive) return; // skip inactive users

  sendWelcomeEmail(user);
  updateAnalytics(user);
}
```

Once those guard clauses are in place, I don’t have to `mentally juggle` those “what ifs” anymore. They’re dealt with.
The rest of the code reads like a straight road.

Before I got into this habit, my functions often looked like a pile of _stacked boxes—each_ if wrapped inside another.
It
worked, but it forced every reader (including future me) to carry all those checks in their head all the way down.

```javascript
function processUser(user) {
  if (user) {
    if (user.isActive) {
      sendWelcomeEmail(user);
      updateAnalytics(user);
    }
  }
}
```

This still runs fine, but it makes you think about conditions long after you should’ve moved on.

The beauty of early return is that it clears `mental space`.

> You make the easy decisions first, exit where needed, and
> leave the interesting logic standing in the light. It’s not just about fewer braces—it’s about respecting your own
> attention span.

It’s funny how these little patterns sneak up on you. Today’s code reminded me that writing for humans, including future
me—is just as important as writing for the machine.


Discover how early return and guard clauses can simplify your JavaScript functions, reduce nesting, and free your mind to focus on the real logic.

Why Early Return Makes Your JavaScript Easier to Read


<Image alt="A hand-drawn diagram showing Generic Type Parameters on the left and a browser window with TypeScript code for a generic identity function on the right, plus two boxes labeled U and V" src="generic.jpg" priority={true} />

When you first encounter TypeScript generics, you'll likely see something
like [this](https://www.typescriptlang.org/docs/handbook/2/generics.html#hello-world-of-generics):

```typescript
function identity<T>(arg: T): T {
  return arg;
}
```

That lonely **T** sitting there might seem mysterious.

Why T? What if you need more than one? And when should you graduate from single letters to something more descriptive?
Let's dive into the world of generic naming conventions and figure out what actually makes sense.

## The Classic Lineup: T, U, V, W

The **T** convention comes from mathematics and early programming languages. It simply stands for "Type" – nothing
fancy.
When you need multiple generic parameters, the tradition is to march through the alphabet:

```typescript
// Two types? Add U
function pair<T, U>(first: T, second: U): [T, U] {
  return [first, second];
}

// Three types? Bring in V
function triple<T, U, V>(first: T, second: U, third: V): [T, U, V] {
  return [first, second, third];
}
```

This alphabetical progression isn't arbitrary – it creates a clear, predictable pattern that developers can follow
easily. Plus, these single letters are visually distinct and don't clutter your code.

> This naming convention is common in different languages,
> like [Java](https://docs.oracle.com/javase/tutorial/java/generics/types.html) and others.

## When Single Letters Work Perfectly

For simple, general-purpose functions and utilities, single letters are your best friend:

```typescript
// Array mapping - crystal clear what T and U represent
function map<T, U>(items: T[], transform: (item: T) => U): U[] {
  return items.map(transform);
}

// Key-value pairs - K and V are intuitive
interface Dictionary<K, V> {
  [key: K]: V;
}
```

> Notice how TypeScript's own built-in utilities follow this pattern. `Pick<T, K>`, `Omit<T, K>`, `Record<K, V>` – they
> stick with meaningful single letters because the context makes their purpose obvious.

## The Case for Descriptive Names

Sometimes, though, single letters leave your future self (and your teammates) scratching their heads. That's when
descriptive names shine:

```typescript
// What are T and U supposed to represent here?
interface ApiClient<T, U> {
  get(endpoint: string): Promise<T>;
  handleError(error: U): void;
}

// Much clearer!
interface ApiClient<ResponseData, ErrorType> {
  get(endpoint: string): Promise<ResponseData>;
  handleError(error: ErrorType): void;
}
```

This is especially valuable in domain - specific code where the generic types have special meaning in your business logic.

## The Repository Pattern Example

Here's where descriptive naming really pays off:

```typescript

interface Repository<Entity, Key> {
  findById(id: Key): Promise<Entity | null>;
  save(entity: Entity): Promise<Key>;
  delete(id: Key): Promise<void>;
  findAll(): Promise<Entity[]>;
}


class UserRepository implements Repository<User, string> {
  // Implementation details...
}
```

Anyone reading this code immediately understands what **Entity** and **Key** represent.
Compare that to `Repository<T, U>` – you'd need to dig into the implementation to figure out which is which.

## The T Prefix Debate

You'll sometimes see generic parameters prefixed with T:

```typescript
interface Repository<TEntity, TKey> {
  findById(id: TKey): Promise<TEntity>;
}
```

This convention comes from [C#](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic?view=net-9.0) and serves a purpose – it clearly marks something as a **type parameter** rather than a
**regular variable**. But it's not universally loved.

TypeScript's own standard library doesn't use the T prefix.
React components rarely use it. Many JavaScript and TypeScript projects skip it entirely:

```typescript
// Both are perfectly valid
interface Props<User, Settings> {}
interface Props<TUser, TSettings> {}
```

The choice often comes down to team preference and consistency with your existing codebase. Pick one style and stick
with it.

## Practical Guidelines

Here's what I've learned from years of writing TypeScript:

### Use single letters when:

- Writing utility functions that work with any type 
- The generic's role is obvious from context 
- You're following established patterns (like `map<T, U>`)

### Use descriptive names when:

- The generics have a specific domain meaning 
- You have multiple related type parameters 
- Code clarity would suffer with single letters

### Stay consistent:

- Whatever convention your team chooses, apply it everywhere 
- Don't mix T prefixes with non-prefixed names randomly 
- Document your team's preferred style

## Common Single-Letter Conventions

```typescript
T // Primary type parameter
U, V, W // Additional type parameters (alphabetical order)
K // Key type (in mappings, records)
V // Value type (in key-value structures)
E // Element type (in collections)
R // Return type
P // Properties/Props type
```

## Wrapping Up

- **Consistency beats perfection** – pick a style and stick with it 
- **Context is king – choose names** that make sense for your specific use case 
- **When in doubt, be descriptive** – clarity trumps brevity in complex code 
- **Follow your team's conventions** – consistency across the codebase matters most

> I love conventions and wrote a lot of articles about them.
> Check out about [conventional commits](/blog/conventional-commits) and [JavaScript Naming](/blog/javascript-naming-conventions) for more.


Learn TypeScript generic type parameter naming conventions. Understand when to use T, K, V and when descriptive names like TKey make your code more readable.

What is a generic type parameter T in TypeScript?


Hey there, TypeScript fans!

Ever found yourself wrestling with complex types and wishing there was a better way? Well,
buckle up, because we're about to dive into the world of discriminated unions. 🚀

## What Are Discriminated Unions?

Okay, so `discriminated unions` sounds like some fancy computer science term (and yeah, it kind of is), but don't let
that scare you off. Think of them as TypeScript's way of saying, "Hey, this thing can be one of these specific types,
and here's an easy way to figure out which one it is."

It's like having a box of assorted candies, but each candy has a little flag sticking out of it telling you what flavor
it is 🍭. That flag? That's our discriminant. Neat, right?

## How to Create a Discriminated Union

Let's break it down into easy steps:

1. Come up with the different "flavors" your type can be.
2. Give each flavor a special property (our little flag) that says what it is.
3. Throw them all together into one super-type.

Here's what it looks like in action:

```typescript
interface Taco {
  kind: "taco";
  shells: number;
}

interface Burrito {
  kind: "burrito";
  length: number;
}

interface Nachos {
  kind: "nachos";
  toppings: string[];
}

type MexicanFood = Taco | Burrito | Nachos;
```

In this tasty example, `kind` is our special flag (discriminant), and `MexicanFood` is our super-type. Each specific
type
(`Taco`, `Burrito`, `Nachos`) has its own `kind` property that tells TypeScript what it is.

## Why Discriminated Unions Are Awesome

1. **TypeScript becomes psychic**: It can magically figure out which specific type you're dealing with. No more guessing
   games!

2. **Your code tells a story**: Anyone reading your code can quickly understand what's going on. It's like leaving good
   comments, but better.

3. **Catch mistakes before they happen**: TypeScript can warn you if you forget to handle a case. It's like having a
   really attentive proofreader.

4. **Your IDE becomes smarter**: Better autocomplete suggestions? Yes, please!

## Discriminated Unions in Action

Let's see how we can use our `MexicanFood` type:

```typescript
function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      return food.shells * 200; // TypeScript knows it's a Taco!
    case "burrito":
      return food.length * 100; // It's definitely a Burrito here
    case "nachos":
      return food.toppings.length * 50; // Nacho time!
  }
}
```

TypeScript's got your back here. It knows exactly what properties are available in each case. Pretty cool, huh?

## Pro Tip: Don't Forget Any Cases!

Want to make sure you've covered all your ? Here's a neat trick:

```typescript
function assertNever(x: never): never {
  throw new Error("Unexpected food: " + x);
}

function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      return food.shells * 200;
    case "burrito":
      return food.length * 100;
    case "nachos":
      return food.toppings.length * 50;
    default:
      return assertNever(food); // TypeScript will complain if you miss a case
  }
}
```

> We will discuss the `assertNever` function in a future post.

If you add a new type of food but forget to update `getCalories`, TypeScript will give you a heads-up. It's like having
a friendly reminder bot!

## Discriminated Unions of Tuples

Sometimes, you might want to use a discriminated union with tuples. Here's how you can do it:

```typescript
type User = { id: number, name: string }; // User type
type APIResponse = [success: true, data: User] | [success: false, error: string]; // Tuple type

function handleResponse(response: APIResponse): void {
  const [success, data] = response;

  if (success) {
    const { id, name } = data; // TypeScript knows it's a User!
    console.log(`User ${name} with ID ${id} found!`);
  } else {
    //  TypeScript knows it's an error string!
    console.error(`Error: ${data}`);
  }
}
````


## Discriminated Unions and Destructuring
Discriminated unions are awesome, but they're not perfect. One of the main drawbacks is that you can't use them with destructuring.

```typescript
function getCalories({ kind, shells, length, toppings }: MexicanFood): number {
  // Error: Property 'shells' does not exist on type 'MexicanFood'.
  // Error: Property 'length' does not exist on type 'MexicanFood'.
  // Error: Property 'toppings' does not exist on type 'MexicanFood'.
}
```

So, if you need to destructure your object, you'll have to do it the more explicit way:

```typescript
function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      const { shells } = food; // TypeScript knows it's a Taco! And you can destructure here
      return shells * 200;
    case "burrito":
      const { length } = food;
      return length * 100;
    case "nachos":
      const { toppings } = food;
      return toppings.length * 50;
  }
}
```

## Wrapping Up

[Discriminated unions](https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions) in TypeScript are like the Swiss Army knife of type management. They help you write code that's
easier to understand, harder to mess up, and just plain cooler.

Next time you're dealing with a bunch of related but different types, give discriminated unions a shot. Your future
self (and your teammates) will thank you!

Happy coding, and may your types always be discriminated! 🚀✨


Discover how discriminated unions in TypeScript help you write cleaner, safer code. Learn what they are, how to use them, and why they're great!

Discriminated Unions in TypeScript: The Secret Sauce for Better Code


<Image src="html.jpg" alt="White smartphone on two softbound books" />

## HTML Class Naming Conventions with BEM Methodology: Enhancing CSS Naming Conventions

As a web developer, you understand the importance of keeping your codebase clean and maintainable. One of the crucial
aspects of achieving this goal is following HTML class naming conventions.

In this article, we'll delve into the world of HTML class naming conventions, with a specific focus on
the [BEM](https://www.educative.io/answers/what-is-a-css-class-naming-convention) (Block,
Element, Modifier) methodology.
We'll explore how this approach enhances CSS naming conventions, improves code readability, and makes your codebase more
organized.

### Understanding the Importance of HTML Class Naming Conventions

Effective HTML class naming conventions are vital for several reasons:

1. **Readability:** Well-structured class names make your HTML and CSS easier to understand, even for developers who
   didn't write the code.

2. **Maintainability:** Properly named classes simplify the process of making changes or additions to your code,
   reducing the risk of breaking existing styles.

3. **Collaboration:** Naming conventions facilitate collaboration among team members, making it easier to work on the
   same codebase.

4. **Scalability:** Consistent class naming conventions are essential for managing large projects and ensuring they
   remain scalable.

### BEM Methodology: A CSS Class Naming Convention

BEM, which stands for Block, Element, Modifier, is
a [popular CSS class naming convention](https://en.bem.info/methodology/naming-convention/). It provides a structured
and consistent approach to [naming](https://getbem.com/naming/) classes. Let's break down the components of BEM:

#### 1. **Block**

A block is a standalone component that represents a high-level element or a module on a web page. It's usually a
container for one or more elements within it.

```html

<div class="block">
  ...
</div>
```

#### 2. **Element**

An element is a part of a block and is semantically tied to it. It is named using a double underscore (`__`) as a
separator.

```html

<div class="block">
  <div class="block__element">
    ...
  </div>
</div>
```

#### 3. **Modifier**

A modifier is used to change the appearance, behavior, or state of a block or element. It's named using a double
hyphen (`--`) as a separator.

```html

<div class="block">
  <div class="block__element">
    ...
  </div>
</div>

<div class="block block--modifier">
  ...
</div>

<div class="block__element block__element--modifier">
  ...
</div>
```

### Examples of BEM Methodology in Action

Let's see how BEM methodology applies to real-world examples:

#### Navigation Menu

```html

<nav class="navigation">
  <ul class="navigation__list">
    <li class="navigation__item">
      <a class="navigation__link" href="#">Home</a>
    </li>

    <li class="navigation__item navigation__item--active">
      <a class="navigation__link" href="#">About</a>
    </li>
  </ul>
</nav>
```

In this example, the block is the `navigation`, and its elements and modifiers are clearly defined, making it easy
to understand and style.

#### Article Card

```html

<article class="article-card">
  <header class="article-card__header">
    <h2 class="article-card__title">An Exciting Blog Post</h2>
  </header>
  
  <div class="article-card__content">
    <p class="article-card__paragraph">...</p>
  </div>
  
  <footer class="article-card__footer article-card__footer--featured">
    <a class="article-card__link" href="#">Read More</a>
  </footer>
</article>
```

In this example, the `article-card` block contains elements like `header`, `content`, and `footer`. The `footer` block
also has a modifier indicating that it's featured.

### Enhancing HTML Element Selection

By adhering to BEM methodology, you not only improve naming conventions for CSS but also enhance HTML element selection.
This structured approach to naming classes makes it easier to target specific elements when applying styles.

### CSS Properties and Background Colors

CSS properties and background colors become more manageable with BEM. You can quickly identify and update styles for
individual elements, maintaining consistency throughout your web page.

### In Conclusion

Incorporating BEM methodology into your HTML class naming conventions not only enhances CSS naming conventions but also
improves the overall quality of your code. The structured approach ensures that your codebase remains clean, organized,
and easily understandable. By adopting these practices, you can create web pages that are more maintainable,
collaborative, and scalable, promoting a seamless web development experience.

Embrace BEM and watch your HTML and CSS codebase flourish, all while adhering to effective naming conventions for your
HTML elements and CSS selectors.

For further reading on CSS and HTML best practices, consider checking out these additional resources:

- [CSS Naming Conventions on MakeUseOf](https://www.makeuseof.com/css-class-and-id-best-naming-practices/)
- [FreeCodeCamp's CSS Naming Conventions Guide](https://www.freecodecamp.org/news/css-naming-conventions-that-will-save-you-hours-of-debugging-35cea737d849/)
- [Scaler's CSS Class Naming Convention Article](https://www.scaler.com/topics/css-class-naming-convention/)
- [StackOverflow Discussion on CSS Class Naming Conventions](https://stackoverflow.com/questions/7927193/css-class-naming-convention)
- [HackerNoon's Article on CSS Organization and Naming Conventions](https://hackernoon.com/best-practice-in-css-organisation-and-naming-conventions-4d103ujy)
- [CSS Naming Conventions on CSS-Tricks](https://css-tricks.com/bem-101/)
- [LinkedIn Discussion on HTML Class and ID Naming](https://www.linkedin.com/advice/1/how-do-you-name-html-classes-ids-skills-html)

These references will provide you with comprehensive insights into web development best practices, ensuring you're
equipped with the knowledge to create outstanding web pages.

If you're looking for more examples and guidelines for BEM class name you can find it on my snippet page
about [Common CSS Class Names](/snippets/common-css-classes).


Discover the art of crafting clean HTML class names with BEM methodology. Learn to create maintainable, scalable, and SEO-friendly CSS code.

Advanced HTML Class Naming Strategies for CSS Efficiency


## ❌ Problem

In my opinion, one of the most important tasks when writing code is to make it as simple and understandable as possible.
There are even principles in programming aimed at this - [KISS](https://en.wikipedia.org/wiki/KISS_principle).

You can often see such code with a lot of `if`, and `switch` statements in tutorials or answers on StackOverflow:

```js
function handleUserMove(direction) {
  if (direction === 'north') {
    movePlayerTo("north");
  } else if (direction === 'east') {
    movePlayerTo("east");
  } else if (direction === 'south') {
    movePlayerTo("south");
  } else if (direction === 'west') {
    movePlayerTo("west");
  } else {
    console.error("Unknown direction");
  }
}
```

If we had more conditionals who know how long this `if/else` statement could get 🤯, and it's not very dynamic.

We can use a `switch` statement:

```js
function handleUserMove(direction) {
  switch (direction) {
    case "north":
      movePlayerTo("north");
      break;
    case "east":
      movePlayerTo("east");
      break;
    case "south":
      movePlayerTo("south");
      break;
    case "west":
      movePlayerTo("west");
      break;
    default:
      console.error("Unknown direction");
  }
}
```

Although there is a little more code, `switch` itself describes the dispatching process more explicitly, but we write a
lot of static (control) code, and we must not forget about `break`. Too complicated for such a simple task.

## ✅ Solution

So what can we do to simplify it?

```js
const userInputToDirection = {
  north: movePlayer("north"),
  east: movePlayer("east"),
  south: movePlayer("south"),
  west: movePlayer("west")
}

function handleUserMove(direction) {
  userInputToDirection[direction]();
}
```

This option is better than the previous two for several reasons:

- It is shorter
- It is more flexible. Conditional constructs are static code that cannot be changed without rewriting the program
  itself.
- With
  the [Single Responsibility Principle (SRP)](https://www.freecodecamp.org/news/solid-principles-single-responsibility-principle-explained)
  , we have separated the execution function of our `handleUserMove` business logic from the direction determination
  logic.

Conditional constructs are static code that cannot be changed without rewriting the program itself.
But data is a completely different matter.
With this approach, it is easy to add new behavior without changing the application code `handleUserMove` itself.

## Real example

For example, in Next.js applications, you can
configure [next.config.js](https://nextjs.org/docs/pages/api-reference/config/next-config-js) and the code there looks
like this:

```js
const nextConfig = {
  /* Next.js config options here */
}

let resultConfig;

if (process.env.NODE_ENV === 'development') {
  resultConfig = withBundleAnalyzer(nextConfig);
} else if (process.env.NODE_ENV === 'production') {
  resultConfig = withSentryConfig(nextConfig);
} else if (process.env.NODE_ENV === 'test') {
  resultConfig = nextConfig;
}

module.exports = resultConfig;
```

With new knowledge, we can rewrite it like this:

```js
const nextConfigByEnv = {
  development: withBundleAnalyzer(nextConfig),
  production: withSentryConfig(nextConfig),
  test: nextConfig,
};

module.exports = nextConfigByEnv[process.env.NODE_ENV];
```

Will it look and read much better? I use [dispatch tables](/blog/introducing-the-new-shramko.dev#monitoring-with-sentry) in my projects, and I can say that it is a very convenient.

## Useful links

- [Example in CLI parser app](https://github.com/Shramkoweb/CLI-diff-generator/blob/develop/src/parsers.js#L31)
- [Naming Conventions for Key-Value Maps](https://softwareas.com/naming-conventions-for-key-value-maps/)
- [Dispatch table](https://en.wikipedia.org/wiki/Dispatch_table)


Replace messy switch statements with dispatch tables in JavaScript. Learn this clean code pattern for handling multiple conditions with maintainable code.

Dispatch Tables in JavaScript: A Clean Code Approach


JavaScript distinguishes _expressions_ and _statements_. A statement is an instruction, an action.

Remember conditions with `if`, `loops` with `while` and `for` — all those are _statements_, because they just perform
actions and control actions, but don't become values.

`Expression` returns (expresses) a value. Each of the following lines contains an expression:

```js
100 // this is a literal that expresses number 100

getUserName() // expresses Serhii

5 + 2 // expresses 7
```

`Statements` produce or control actions, but do not turn into values:

```js
let x; // declare a variable 'x'

function foo() {} // declare a function 'foo'

function bar() {
  return null // return is also a statement
}
```

You can't put statements where expressions are expected. For example, passing a const statement as a function
argument will produce an error. Or trying to assign the if statement to a variable:

```js
let b = if (x > 10) { return 100; };  // error!

console.log(const y);  // error!
```

## Related posts

- [Expressions versus statements in JavaScript](https://2ality.com/2012/09/expressions-vs-statements.html)
- [Expressions - MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Expressions_and_operators)


Learn the difference between expressions and statements in JavaScript. Understanding this distinction helps you write better code and avoid syntax errors.

JavaScript Expressions vs Statements: What's the Difference?

Write maintainable code with proven clean code principles. Learn refactoring, naming conventions, and patterns that reduce technical debt.

Clean Code6 articles

Articles

The early return pattern in JavaScript

Generic Type Parameters in TypeScript

Discriminated Unions in TypeScript

Mastering HTML Class Naming: Boosting CSS Efficiency

Dispatch table in javascript

Expressions vs Statements