<Image src="seo.jpg" alt="Ahrefs SEO audit dashboard showing website health score and issues" priority={true} />

I've been putting off an SEO audit of my blog for months. With **30+** articles and **20+** code snippets, the task felt overwhelming. Reviewing each meta description, checking for broken links, validating alt text — it's the kind of work that's *easy to procrastinate* on indefinitely.

Then I tried something different: I used AI as my editorial assistant. In a single afternoon, I audited and improved **56 files**. Here's how it went.

## The Boring Work Nobody Wants to Do

Let's be honest — SEO maintenance is *boring*. It's not the exciting part of running a developer blog. You know you should do it, but there's always something more interesting to work on.

My blog had accumulated typical SEO debt over time. Generic meta descriptions that said nothing specific, like "Learn about X" instead of actual summaries. Broken external links because MDN reorganized their docs and Git changed their download URL. Empty alt attributes on images where I'd rushed through posts and left `alt=""`. The usual mess.

Fixing this manually would mean opening each file, reading the content, rewriting descriptions, and validating every link. For 56 files? That's a full weekend I'd *never* actually spend.

## Teaching AI What I Need

The key insight was treating AI not as a magic "fix everything" button, but as a *focused assistant* with clear constraints. I use [Cursor](https://www.cursor.com/) as my editor, and it supports [project-specific rules](https://docs.cursor.com/context/rules) — markdown files that act as persistent instructions for the AI.

I created a rules file (`.cursor/rules/seo.mdc`) that defined exactly what I needed:

```markdown
SEO responsibilities:
- Propose 2–5 realistic, developer-focused keyword phrases for each article
- Suggest an SEO-friendly title (50-60 characters) and meta description (110-160 characters)
- Naturally integrate the main keyword into title, first paragraph, and conclusion
- Never sacrifice clarity or honesty for SEO
```

This file acts as persistent context. Every time the AI reviews an article, it knows who I am (a senior software engineer), who my audience is (developers from junior to senior level), my writing style (conversational, direct, technical), and what to avoid (inventing experience, adding buzzwords, breaking code).

That last constraint — *"never sacrifice clarity for SEO"* — is crucial. I've seen AI-generated content stuffed with keywords that reads like garbage. That's not what I wanted.

## What the SEO Audit Found

<Image src="ahrefs-audit.png" alt="Ahrefs Site Audit results showing SEO issues to fix" />

**Before:**
```text
description: Polymorphism and Dispatch Tables in JS
```

**After:**
```text
description: Replace messy switch statements with dispatch tables in JavaScript. 
Learn this clean code pattern for handling multiple conditions with maintainable code.
```

The first one tells you nothing. The second *explains the benefit*, uses action words, and includes relevant keywords naturally.

MDN restructured their documentation URLs at some point too. Links that worked a year ago now 404. The AI flagged these:

```diff
- [CSS Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout)
+ [CSS Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Grid_layout)
```

Same for Flexbox and other external resources. Small fixes, but broken links hurt both SEO and user experience.

Then there was alt text. In my React re-renders article, I had multiple images with *empty* alt attributes:

```diff
- <Image alt="" src="rerender.png" />
+ <Image alt="Diagram showing React component tree re-rendering when state updates" src="rerender.png" />
```

The AI suggested appropriate descriptions based on the surrounding content in seconds.

## Wrapping Up

The goal here isn't to automate away quality control. It's to make the tedious parts *fast enough* that you actually do them.

By the end of the afternoon: **56 files** updated, **50+ meta descriptions** rewritten, **6 broken links** fixed, **12 empty alt attributes** filled.

I used Cursor AI to audit SEO across 56 blog posts in one afternoon. Meta descriptions, broken links, and alt text — all fixed systematically.

I Ran an AI SEO Audit on 56 Blog Posts in One Day

<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?

<Image src="git.jpg" alt="Hand-drawn illustration of the Git logo inside a tilted square outline with three red dots connected by black lines, representing branches" priority={true} />

When it comes to managing version control in your project with Git, `.gitignore` files typically handle most cases of
excluding specific files or directories from being tracked. However, there are instances when you either can’t or simply
prefer not to modify the `.gitignore` file directly.

Fortunately, Git offers several alternative methods to tackle these scenarios effectively.

### Why You Might Want to Avoid Modifying .gitignore

There are generally two key situations where you might opt to keep your `.gitignore` unchanged:

1. **Personal or local-specific files:** Say you have custom settings or environment files (like `.envrc` or
 personalized
 IDE configurations). You wouldn’t want to clutter the repository with your personal preferences that aren’t relevant
 to others.
2. **Temporarily ignoring changes to tracked files:** Perhaps you’re making adjustments to a file that’s already under
 version control (such as a Docker configuration or database settings), but you want to ensure these changes don’t
 appear in every commit.

Here’s how to handle both situations gracefully.

### Ignoring untracked files

Git provides a straightforward solution that keeps personal preferences out of sight from collaborators: the
`.git/info/exclude` file. This file acts just like `.gitignore` but remains local—meaning your teammates won’t be
affected
by your individual exclusions.

To put this into action, simply open the `.git/info/exclude` file in your repository and list the files or directories
you
wish to ignore:

```gitignore
.idea/
*.log
.env.local
```

Now, your IDE settings, log files, or local environment configurations will no longer clutter your Git status or lead to
accidental commits without interrupting your teammates’ workflow.

### Temporarily Ignoring Changes with git update-index

At some point, you’ll find it necessary to tweak files you’re already tracking, but you have no intention of committing
those changes (for example, adjusting local ports or temporary debugging code). That’s where the
`git update-index --assume-unchanged` command comes in.

Here’s how it works:

To temporarily ignore changes in a tracked file, simply run:

```bash
git update-index --assume-unchanged docker-compose.yml
```

This command tells Git to overlook any further changes made to `docker-compose.yml`, treating it as if it hasn’t been
modified.

However, use this feature with caution! Overuse can lead to confusion, especially if you forget you’ve set it. To resume
tracking the changes, you can run:

```bash
git update-index --no-assume-unchanged docker-compose.yml
```

If you ever need a quick way to check which files are being ignored, you can use:

```bash
git ls-files -v | grep '^h'
```

This command lists the files that Git currently assumes are unchanged, helping you maintain organization.

### Final Thoughts

While `.gitignore` is a powerful tool, it’s not always enough on its own. By incorporating `.git/info/exclude` and the
`git update-index` technique into your toolkit, you can enjoy greater flexibility in managing your repository.

Precise management leads to fewer headaches and cleaner commits, ensuring a smoother and more intuitive approach to
version control.

Learn about Git's hidden alternatives to .gitignore for managing file exclusions locally without affecting your team's workflow.

When .gitignore Isn't the Right Tool


Writing clean, maintainable JavaScript isn't just about making your code work - it's about making it understandable. In
this comprehensive guide, we'll explore the essential naming conventions that can transform your JavaScript code from
merely functional to professionally polished.

## Why Naming Matters in JavaScript

Every time you write code, you're not just writing it for the computer - you're writing it for other developers (
**including your future self** ). Good naming conventions serve as a form of documentation, making your code self-explanatory
and reducing the cognitive load required to understand it.

## Core Principles of JavaScript Naming

### 1. Consistency Is Key

The most fundamental rule of naming in JavaScript is maintaining consistency throughout your project. Whether you choose
camelCase or snake_case, stick to it. Here's why:

- Reduces cognitive overhead for developers
- Makes code more predictable
- Simplifies maintenance and refactoring
- Improves team collaboration

### 2. Language Matters

While JavaScript is flexible enough to allow variable names in any language, stick to English. This ensures:

- Universal code readability
- Easier collaboration with international teams
- Better integration with existing codebases

### 3. The Case for Different Cases

JavaScript uses multiple naming conventions depending on the context:

- `camelCase` for variables, functions, and methods
- `PascalCase` for classes and constructor functions
- `UPPER_SNAKE_CASE` for constants
- `kebab-case` typically for CSS classes and HTML attributes

JavaScript’s built-in APIs use camelCase (e.g., getElementById), PascalCase for classes (e.g., Date), and UPPER_SNAKE_CASE for constants (e.g., Math.PI). Align your code with these patterns.

## Practical Naming Guidelines

### Variables and Functions

#### Boolean Variables

Boolean variables should start with an affirmative prefix, typically 'is' or 'has':

```javascript
// Bad ❌
const active = true;
const notAllowed = !user.checkAccess();

// Good ✅
const isActive = true;
const hasPermission = user.checkAccess();
```

> Another thing to remember at the conference is that the affirmative prefix shouldn't include a negation. This is because the negation operator (!) is most commonly used with Boolean values. So, a value named something like 'isNotAllowed' with the negation applied to it, '!isNotAllowed', can be quite misleading.

Naming recommendations for Boolean from [W3C](https://w3ctag.github.io/design-principles/#naming-booleans).

#### Functions and Methods

Function names should be verbs that clearly describe their action:

```javascript
// Bad ❌
function userData() {}

function total() {}

// Good ✅
function getUserData() {}

function calculateTotal() {}
```

### Collections and Arrays

Use plural nouns for arrays and collections:

```javascript
// Bad ❌
const userRoleList = ['admin', 'editor', 'viewer'];
const activeUserArr = new Set();

// Good ✅
const userRoles = ['admin', 'editor', 'viewer'];
const activeUsers = new Set();
```

### Classes and Objects

#### Class Names

Classes should use PascalCase and be noun phrases:

```javascript
// Bad ❌
class userService {
  constructor() {}
}

// Good ✅
class UserService {
  constructor() {}
}
```

#### Class Members

Avoid repeating the class name in member names:

```javascript
// Bad ❌
class UserProfile {
  updateUserProfile() {}

  deleteUserProfile() {}
}

// Good ✅
class UserProfile {
  update() {}

  delete() {}
}
```

### Constants and Enums

#### Constants

Use UPPER_SNAKE_CASE for true constants:

```javascript
// Bad ❌
const maxRetryAttempts = 3;
const apiBaseUrl = 'https://api.example.com';

// Good ✅
const MAX_RETRY_ATTEMPTS = 3;
const API_BASE_URL = 'https://api.example.com';
```

#### Enums

Use PascalCase for enum names and UPPER_SNAKE_CASE for enum values:

```javascript
// Bad ❌
const userRoles = {
  admin: 'admin',
  editor: 'editor',
  viewer: 'viewer'
};

// Good ✅
const UserRole = {
  ADMIN: 'admin',
  EDITOR: 'editor',
  VIEWER: 'viewer'
};
```

#### Maps
Also known as a dictionary data structure. This data structure is used for mapping one value to another.

```javascript
// Bad ❌
const userRole = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const REDIRECTING = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const UserPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}

// Good ✅
const userRoleToReadable = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const pagePathToRedirectPath = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const userRoleToPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}
```

## Common Pitfalls to Avoid

### 1. Including Types in Names

```javascript
// Bad ❌
const userArray = ['John', 'Jane'];
const nameString = 'John';

// Good ✅
const users = ['John', 'Jane'];
const name = 'John';
```

### 2. Ambiguous Abbreviations

```javascript
// Bad ❌
const usr = getUser();
const pwd = 'secret';

// Good ✅
const user = getUser();
const password = 'secret';
```

### 3. Inconsistent Naming Patterns

```javascript
// Bad ❌
const get_user = () => {};
const fetchData = () => {};
const retrieve_info = () => {};

// Good ✅
const getUser = () => {};
const fetchData = () => {};
const retrieveInfo = () => {};
```

### 4. Different Languages
```javascript
// Bad ❌
const ユーザー名 = "John";

// Good ✅
const userName = "John";
```

## Types & Interfaces

Names of types and interfaces should be written in `PascalCase` notation.

```typescript
// Bad  ❌
type TUser = {
  firstName: string
  lastName: string
}

interface userServiceInterface {
  findByEmail: (email: string) => User
}

// Good ✅
type User = {
  firstName: string
  lastName: string
}

interface UserServiceContract {
  findByEmail: (email: string) => User
}

interface IUserService {
  findByEmail: (email: string) => User
}
```

> When engineering teams choose to leverage both class-based types and abstract definitions within the same project, best practices suggest adding a distinguishing marker to the abstract definitions. Common prefix choices include `T` and `Contract`.

## Tools for Maintaining Naming Conventions

To help maintain consistent naming conventions, consider using:

1. [ESLint](https://eslint.org/) with naming convention rules
2. [Prettier](https://prettier.io/) for consistent formatting
3. IDE extensions for code style enforcement
4. Team code review guidelines focused on naming

## Time Tested Naming Naming Conventions
- [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html#naming)
- [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript?tab=readme-ov-file#naming-conventions) 

## Conclusion

Good naming conventions are more than just style preferences - they're a fundamental aspect of writing maintainable,
professional JavaScript code. By following these conventions consistently and thoughtfully, you'll create code that's
easier to understand, maintain, and debug.

Remember, the goal isn't to follow these rules blindly, but to use them as guidelines to write more readable and
maintainable code. The best naming convention is one that your entire team understands and follows consistently.

## Related Content

- [CSS Class Naming Conventions](/blog/class-naming-conventions) - BEM methodology for HTML/CSS
- [Common CSS Class Names](/snippets/common-css-classes) - practical BEM class name examples


Master JavaScript naming conventions with this guide. Learn best practices for naming variables, functions, and classes to write cleaner code.

JavaScript Naming Conventions: A Complete Guide for Clean Code

<Image src="conventional-commits.jpg" alt="Conventional Commits. A close up of a text description on a computer screen." />

I first came across Conventional Commits during my time at [MacPaw](/about), but initially, I didn't give much thought
to these unique commit messages.
It wasn't until recently that I took a closer look and realized how much more efficient and organized they make the
development process.

Here’s why you might want to give them a try too! 😃

## What Are Conventional Commits?

Conventional Commits is a specification that provides a simple, structured convention for commit messages.
It allows to write messages that are easy to read and maintain, and which convey the specific intent behind each
change.

The conventional commit message format is straightforward. It starts with a **type**, optionally followed by a **scope
**, and a
short **description**. For example:

```bash
feat(login): add authentication with JWT
```

In this example:

- `feat` is the type of the commit, indicating a new feature.
- `login` is the scope, specifying the part of the project that is affected.
- `add authentication with JWT` is the short description of the change.

## Why Use Conventional Commits?

Using Conventional Commits offers several key benefits:

- `Consistency`: Standardized commit messages ensure that everyone on the team follows the same format, which enhances
 readability and reduces ambiguity.
- `Automation`: Tools can automatically generate change logs, version numbers, and releases based on the structured
 commit messages.
- `Collaboration`: Clear and descriptive commit messages help team members understand the history and context of
 changes, improving collaboration.
- `Compliance`: Adhering to a standardized format helps in meeting the guidelines and best practices of many open-source
 projects.

## Types of Conventional Commits

There are several predefined types of Conventional Commits that help categorize the nature of each change. Each type
indicates a specific kind of modification, making it easier to understand the impact of the commit. Here are the most
commonly used types:

- **feat**: A new feature for the user.
- **fix**: A bug fix for the user.
- **chore**: Changes that don't modify src or test files, such as updating build tasks.
- **docs**: Documentation-only changes.
- **style**: Changes that do not affect the meaning of the code (e.g., formatting, missing semicolons, etc.).
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **perf**: A code change that improves performance.
- **test**: Adding or updating tests.
- **build**: Changes that affect the build system or external dependencies (e.g., gulp, npm).
- **ci**: Changes to CI configuration files and scripts (e.g., CircleCI, Travis).
- **revert**: Reverts a previous commit.

## Cheat Sheet for Conventional Commits

<Image src="conventional-commits-cheatsheet.png" alt="Conventional Commits Cheatsheet" />

| Type | Description | Example |
|:---------|:---------------------------|:---------------------------------|
| feat | New feature | feat(ui): add dark mode |
| fix | Bug fix | fix(api): resolve login issue |
| docs | Documentation only changes | docs(readme): update setup guide |
| style | Code style changes only | style(css): format CSS classes |
| refactor | Code refactoring | refactor(auth): optimize logic |
| perf | Performance improvement | perf(database): optimize queries |
| test | Adding tests | test(routes): add unit tests |
| chore | Build tool/config changes | chore(deps): bump dependencies |
| ci | Continuous Integration | ci(travis): update config |
| revert | Revert previous commit | revert: rollback last change |

## Leveraging AI with Conventional Commits

AI-powered IDEs like **JetBrains'** suite of tools enhances your workflow by intelligently suggesting commit messages that
adhere to Conventional Commits standards. These suggestions are contextually generated based on changes you've made,
significantly streamlining the process and reducing the cognitive load of writing detailed commit messages.

### AI-Powered IDEs and Conventional Commits

JetBrains IDEs, such as IntelliJ IDEA and WebStorm, integrate [AI tools](https://www.jetbrains.com/ai-assistant/) that:

- Automatically suggest precise commit messages.
- Detect commit types (feat, fix, docs, etc.) based on changes.
- Recommend appropriate scopes, improving accuracy and efficiency.

## Examples of Conventional Commits

Understanding the theory behind Conventional Commits is one thing, but seeing how they are applied in real-world
scenarios can be extremely helpful. Below are some examples illustrating how to write effective, clear, and standardized
commit messages.

> Here example of commits from [my GitHub](https://github.com/Shramkoweb/Portfolio/commits/develop/)

### Example 1: Adding a New Feature

**Commit Message**:

```bash
feat(auth): add OAuth 2.0 authentication
```

**Explanation**:

**Type**: `feat` (indicates a new feature). 
**Scope**: `auth` (specifies that the change is related to authentication). 
**Description**: `add OAuth 2.0 authentication` (brief summary of the change).

### Example 2: Fixing a Bug

**Commit Message**:

```bash
fix(profile): resolve issue with avatar upload
```

**Explanation**:

**Type**: `fix` (indicates a bug fix). 
**Scope**: `profile` (specifies that the change affects the profile feature). 
**Description**: `resolve issue with avatar upload` (briefly describes the problem and solution).

### Example 3: Updating Documentation

**Commit Message**:

```bash
docs(readme): update installation instructions
```

**Explanation**:

**Type**: `docs` (indicates a documentation change). 
**Scope**: `readme` (specifies the README file). 
**Description**: `update installation instructions` (details the specific update).

### Example 4: Refactoring Code

**Commit Message**:

```bash
refactor(utils): simplify the date parsing logic
```

**Explanation**:

**Type**: `refactor` (indicates a code change that neither fixes a bug nor adds a feature). 
**Scope**: `utils` (specifies that the change pertains to utility functions). 
**Description**: `simplify the date parsing logic` (briefly describes the refactoring).

### Example 5: Performance Improvement

**Commit Message**:

```bash
perf(db): optimize query execution time
```

**Explanation**:

**Type**: `perf` (indicates a performance improvement). 
**Scope**: `db` (specifies that the change affects the database). 
**Description**: `optimize query execution time` (summarizes the performance enhancement).

### Example 6: Adding or Updating Tests

**Commit Message**:

```bash
test(router): add unit tests for routing module
```

**Explanation**:

**Type**: `test` (indicates test-related changes). 
**Scope**: `router` (specifies the routing module). 
**Description**: `add unit tests for routing module` (briefly describes the tests added).

### Example 7: Maintenance or Chore

**Commit Message**:

```bash
chore(deps): upgrade lodash to version 4.17.21
```

**Explanation**:

**Type**: `chore` (indicates maintenance or chores). 
**Scope**: `deps` (specifies that the change pertains to dependencies). 
**Description**: `upgrade lodash to version 4.17.21` (details the specific update).

### Example 8: Continuous Integration Configuration

**Commit Message**:

```bash
ci(circleci): add build step for linting
```

**Explanation**:

**Type**: `ci` (indicates changes to CI configuration). 
**Scope**: `circleci` (specifies the CI service being configured). 
**Description**: `add build step for linting` (briefly describes the new CI step).

### Example 9: Reverting a Previous Commit

**Commit Message**:

```bash
revert: remove OAuth 2.0 authentication

This reverts commit abc123.
```

**Explanation**:

**Type**: `revert` (indicates the commit is a revert). 
**Scope**: None (reverts don't usually need a scope). 
**Description**: `remove OAuth 2.0 authentication` (describes what is being reverted).
Body: This reverts commit abc123. (provides context by specifying the commit being reverted).

## Using Conventional Commits in Projects

Incorporating Conventional Commits into your projects can significantly improve code quality and team collaboration.
Here’s a step-by-step guide on how to start using Conventional Commits in your projects.

### Step 1: Educate Your Team

Before adopting Conventional Commits, ensure that everyone on your team understands its benefits and guidelines. Share
resources, conduct workshops, or organize short training sessions to help everyone get up to speed.

### Step 2: Set Up Commit Message Linting

To enforce the Conventional Commits standard, you can use tools
like [commitlint](https://github.com/conventional-changelog/commitlint) and [husky](https://typicode.github.io/husky/).
These tools help ensure that
all commit messages adhere to the predefined format.

Example Configuration:

#### Install Dependencies:

```bash
npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
```

#### Configure Commitlint:

Create a new file named `commitlint.config.js` in the root of your project and add the following content:

```js
module.exports = {
 extends: ['@commitlint/config-conventional'],
};
```

#### Set Up Husky Hooks:

The `init` command simplifies setting up husky in a project. It creates a `pre-commit` script in `.husky/` and updates
the prepare script in `package.json`. Modifications can be made later to suit your workflow.

```bash
npx husky init
```

### Step 3: Use Tools and Libraries

Conventional commits can be parsed by tools, and a very nice use-case is that of generating release changelogs.

<Image src="changelog.png" alt="Changelog created from Conventional commits on GitHub page" />

#### Semantic Release:

- Automates the whole package release workflow including determining the next version number, generating the release
 notes, and publishing the package.
- [Semantic Release Documentation](https://semantic-release.gitbook.io/semantic-release)

#### Commitizen:

- A tool that prompts you to fill out the commit message with a CLI, ensuring you follow the Conventional Commits
 standard.
- [Commitizen Documentation](https://github.com/commitizen/cz-cli)

### Step 4: Continuous Integration and Continuous Deployment (CI/CD)

Integrate Conventional Commits with your `CI/CD` pipeline to automate tasks such as generating changelogs and
versioning.

Here’s how you can do it:

#### Changelog Generation:

- Use tools like standard-version to generate changelogs automatically.
- [Standard Version Documentation](https://github.com/conventional-changelog/standard-version)

#### Versioning and Releasing:

- Automate versioning and releasing using tools like Semantic Release.
- Define release steps in your CI configuration (e.g., GitHub Actions, Travis CI).

Example GitHub Actions Configuration for Semantic Release:

```yaml
name: Release
on:
 push:
 branches:
 - main
jobs:
 release:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout Code
 uses: actions/checkout@v2
 - name: Install Node.js
 uses: actions/setup-node@v2
 with:
 node-version: 14
 - name: Install Dependencies
 run: npm install
 - name: Run Semantic Release
 run: npx semantic-release
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

## Conclusion

I hope this blog post has inspired you to delve into conventional commits.

Initially, conventional commits might seem a bit odd, and you might find yourself questioning the format as you make
commits. However, they soon become second nature, and you'll appreciate their impact on your software engineering
practices.

> Conventional commits pair well with [Semantic Versioning](/blog/npm-semantic-versioning) for automated package releases.

Master Conventional Commits to write clear, structured commit messages. Learn the format, types like feat and fix, and how to automate changelog generation.

Conventional Commits enhance your coding practices


Small tasks that we put off can accumulate and ultimately consume much more of our time and energy. One such small yet important task is unsubscribing from annoying email newsletters and notifications.

When you receive a new email with an unnecessary newsletter, it's better to decide to unsubscribe from it right away. Yes, it may take a couple of minutes, but in the future, you'll save yourself a lot of time and nerves by getting rid of constant distractions.

Just like with task automation: when you set up a project once, the time invested in that process will pay off in the future by reducing routine tasks and increasing productivity.

Don't forget that small tasks, if postponed, can turn into a big to-do list. And then you'll have to spend much more time and effort to deal with them. This can become a cause of procrastination and worsen your efficiency.

So, don't procrastinate unsubscribing from newsletters. Take a couple of minutes [[atomic habits](https://jamesclear.com/atomic-habits)] now and get rid of unnecessary distractions in the future.

To make it easier for you to deal with unnecessary newsletters and notifications, here are a few useful resources:

- **[Unroll.me](https://unroll.me/):** This service helps you quickly unsubscribe from multiple newsletters simultaneously, saving you time and effort.

- **[Mailstrom](https://mailstrom.co/):** Allows you to quickly and efficiently manage your email inbox by helping you sort and delete unwanted emails.


Stop letting unwanted emails pile up. Learn why unsubscribing from newsletters immediately saves time, reduces distractions, and keeps your inbox focused.

Opt-Out of Email Newsletters Now for a Clutter-Free Inbox

Personal takes on software development, industry trends, and engineering culture. Honest perspectives on tools and practices.

Opinion7 articles

Articles

SEO Audit with AI: 56 Posts, One Afternoon

The early return pattern in JavaScript

Generic Type Parameters in TypeScript

Ignore files in Git without adding them to .gitignore

Why Are JavaScript Naming Conventions Important?

Conventional Commits

Unsubscribe from Email Newsletters Immediately