Coding Etiquette & Best Practices

Why is Coding Etiquette Important?

When using GitHub, it’s important to remember coding etiquette. Coding etiquette ensures that there is consistency across all versions of your code. It also makes it easier to collaborate with peers and guarantees fewer errors. Poor etiquette can lead to lost work, broken builds, and confusing codebases that no one can maintain.

The goal when writing code is simple: you should be able to go back to a project you wrote years ago and understand everything line by line. It should also be easy for someone else to read your work without needing an explanation. Clean, consistent code is expected in internships, jobs, and any professional environment. These habits keep projects maintainable as they grow—and they make you look like someone who knows what they’re doing.

Naming Conventions

Naming is one of the most underestimated skills in programming. It seems small, but the names you choose determine how readable and professional your code looks.

When naming variables, avoid using random letters or abbreviations that don’t make sense later. For example, use userAge instead of ua, or loginButton instead of btn1. Consistency is key! Be sure to pick a style and stick to it throughout your project.

A few common naming styles include camelCase, snake_case, and PascalCase. Camel case (like userAge) is popular in JavaScript. The first word is lowercase and then the first letter of each following word is uppercase to help distinguish between words. Snake case, on the other hand, (like user_age) is common in Python. It uses all lowercase letters and separates words with underscores. Pascal case (like UserAge) is often used in languages such as C# or Java when naming classes or components. It’s similar to camel case, except that the first letter of the first word is also capitalized. Remember that consistency is what matters most within your codebase.

File names should also be descriptive and clear. Instead of calling something “final.js,” “test2.js,” or “copycopy,” use specific names like navbar.css or mapHandler.js. Those extra seconds you spend naming things properly will save you hours of confusion later.

Organizing Files and Folder Structures

The way you organize your files says a lot about you as a developer. Structured folders make navigation easier and make your project scalable.

Most developers use folders like src (for main source code), components, scripts, styles, and assets. Keeping these separated ensures that someone opening your repository for the first time can immediately understand where everything belongs.

Try to avoid dumping everything into a single folder labeled “misc” or “other.” Also, don’t create endless folder hierarchies. No one should have to click through ten folders to find one file! When someone views your repo on GitHub, it should take seconds to understand how it’s organized.

Writing Comments

Comments are one of the most powerful yet misused tools in coding. They should explain both why something exists along with its function.

Good comments should guide readers. For instance:
“I used a short delay here so everything loads smoothly instead of all at once,”

or

“This loop finds each available facility before updating the map markers.”

You don’t need to comment every line. Just focus on the parts that need extra clarification or are complex.

Overcommenting can actually make code harder to read, so aim for balance. You can also separate major sections with block headers.

For example, you might use something like:

/* Form Validation */

for smaller sections, or create longer visual dividers that run across the page for bigger parts of your code, like this:

// ——————– User Interface Section ——————-

This makes it easier to scroll through your code and instantly spot where each section begins. This ensures your code visually organized and not cluttered.

Writing Modular Reusable Code

If you remember one thing from this blog, let it be: Don’t Repeat Yourself.

Whenever you notice the same logic or pattern repeating, that’s a sign to create a function or component you can reuse. Writing modular code means breaking large sections into single-purpose functions.

Avoid hardcoding values that might change later. Instead, store them in variables or constants. This makes it easier to update your code without searching for every instance manually.

The more reusable your functions are, the faster you can build new projects. Trust me… Your future you will thank you!

Commit Messages

Your commit messages tell the story of your project. They’re how you and others understand what happened and why.

There’s a huge difference between a helpful commit and a useless one.
Good: “Fix spacing in navbar on mobile view.”
Bad: “updated stuff.”

Commits should be small, specific, and intentional. Each one should represent a single logical change. If you cram everything into one giant commit, you’ll make debugging later nearly impossible. Small commits create a timeline you can actually follow.

Branching Etiquette

Never develop directly on the main branch. Branches exist for a reason—they let you experiment safely without breaking working code.

Create new branches for new features, bug fixes, or experiments. Name them clearly, like feature-login, fix-footer, or experiment-filtering. Once a branch is stable and tested, merge it back into main. Then, delete the branch when you’re done to keep your repository organized.

Following these habits prevents chaos and ensures that every version of your project stays clean.

Documentation

Documentation is the instruction manual for your code. It tells others (and your future self) how everything works.

A well-written README is essential. It should explain your project’s purpose, list dependencies, show how to install and run the code, and include any special notes about unusual logic.

Always keep documentation updated as your project evolves. Outdated docs cause confusion, especially for collaborators. Clean documentation also makes your projects more impressive to recruiters.

Code Style Consistency

Every developer follow their own routine when it comes to spacing, indentation, and formatting. Just remember that CONSISTENCY IS KEY!

Whether you prefer two spaces or four, pick one and stay with it. Consistent formatting makes code easier to scan and edit. Tools like Prettier and ESLint can automatically format your code and enforce style rules across your files.

Teams often use style guides to keep everyone on the same page, so it’s good practice to get used to that now.

Another small but noticeable detail is your bracket style. You’ve probably seen two common forms:

Style 1 (same line):

function example() {
// code
}

Style 2 (new line):

function example()
{
// code
}

Both are correct, and neither is necessarily wrong. The important thing is to choose one and stick with it. Different languages and teams prefer different styles. For example, JavaScript and CSS often use the first. On the other hand, C-based languages tend to use the second. What really matters is consistency. Switching back and forth randomly makes your code harder to read. Choose a style that feels natural and visually organized, and keep it the same throughout your files.

Collaboration Etiquette

When working on shared codebases, be respectful and intentional. Always review other people’s work carefully before making edits. Avoid overwriting changes without communicating first.

Even if you’re working alone, practice using pull requests to review your own changes—it builds strong habits. Leave notes, ask questions, and clarify assumptions. Communication is one of the most valuable skills in coding!

Security Etiquette

Never push sensitive information to GitHub. This includes API keys, passwords, and environment files (.env).

That’s what .gitignore is for. It tells GitHub which files to skip when you upload your project. Pushing private data can break your application or even expose your credentials. Keeping secrets out of your repo is one of the simplest but most important security habits.

The “Reader Test”

Before calling any project finished, ask yourself: If someone new opened this file, would they understand it?

Try reading your code out loud or imagining that a classmate is going to use it. If you stumble while explaining something, that’s usually a sign that your logic or naming could be clearer. This simple test helps you catch vague variable names, missing comments, or confusing layout decisions.

To Conclude…

Coding etiquette is about clarity, not perfection. These habits make your projects easier to maintain, debug, and share. They show professionalism, maturity, and pride in your work.

Clean and reusable code stands out, especially when your GitHub becomes your portfolio. In the end, etiquette is important to keep in mind. Respect your future self and everyone who will ever read, use, or learn from your code.