How I Write Clean Code: Simple Habits for Better Programming

There was a time when my code looked like a crime scene—variables had names like a, x1, and temp3, functions stretched longer than an unread novel, and debugging was like solving a murder case with no leads. Every time I revisited old code, it felt like someone else had written it—and that someone was a maniac.

I knew I had to change. Clean code isn’t just about writing less code; it’s about writing better, more readable, maintainable, and efficient code. Here’s how I transformed my messy spaghetti into well-structured, readable, and maintainable code.

---

1. Writing Code Like a Story

Good code should read like a well-written book. Imagine a detective novel where character names change on every page, the plot jumps randomly, and important clues are buried under meaningless details. That’s what bad code feels like.

To fix this, I follow these habits:

✅ Use Meaningful Variable & Function Names

• Instead of tmp, x, or doSomething(), I use descriptive names:

  calculateTotalPrice()  // ✅ Clear & self-explanatory  
  doCalc()               // ❌ Vague & unclear  
  

• Replace x1, temp, result, and similar unclear names with descriptive ones.

✅ Follow the Single Responsibility Principle (SRP)

• One function should do one thing well. If a function needs a paragraph of comments to explain itself, it’s doing too much.

✅ Avoid Magic Numbers & Strings

• Instead of hardcoding numbers, define constants:

  if status == STATUS_APPROVED {  
  

  instead of

  if status == 2 {  
  

 Further Reading: Refactoring Code for Better Readability

---

2. Writing Code for My Future Self (and Others)

A year from now, will I understand my own code? If I need hours to remember what I was thinking, I’ve failed. So, I developed a habit:

✅ Comment the "Why," Not the "What"

// Caching this result to avoid expensive database queries
result := cache.Get("userData")

Instead of:

// Fetching data from cache
result := cache.Get("userData")

(That’s obvious from the code itself!)

✅ Consistent Formatting & Styling

• I use auto-formatters (go fmt in Golang) to avoid battles over tabs vs. spaces.
• Stick to a style guide like Effective Go.

---

3. Eliminating Complexity Before It Kills Me

Once, I wrote a brilliant piece of code. It worked flawlessly—until I tried to change one small thing and the whole system collapsed like a house of cards.

I learned a crucial lesson: Complexity is a silent killer.

✅ Follow the KISS Principle (Keep It Simple, Stupid)

• If I can solve a problem in 10 lines instead of 100, I choose the simpler way.

✅ Refactor Continuously
Every time I revisit old code, I ask myself:

• Can I simplify this logic?
• Can I break this function into smaller, more readable parts?
• Is this code still necessary, or can I delete it? 

 Related Guide: Refactoring Techniques

---

4. Defensive Coding: Writing Code That Fails Gracefully

Bad code blows up unpredictably. Good code fails gracefully.

✅ Always Handle Edge Cases
I assume users will break things:

• What if an API call fails?
• What if the input is empty?
• What if the database connection is lost?

✅ Use Assertions & Logging

if user == nil {
    log.Fatal("User object is nil – unexpected state!")
}

✅ Write Tests Even If I Hate It

• I used to ignore tests until I wasted days debugging issues that a simple test could have caught.
• Now, I always write unit tests to validate critical logic.

---

5. DRY: Stop Writing the Same Code Twice

One day, I noticed that I was copy-pasting the same logic in multiple places. When a bug appeared, I had to fix it in every single copy.

That’s when I embraced DRY (Don’t Repeat Yourself):

✅ Refactor Repeated Code into Functions

// Instead of repeating this everywhere
discountedPrice := price * 0.9

// Use a function
func applyDiscount(price float64) float64 {
    return price * 0.9
}

✅ Use Constants for Repeated Values

const ROLE_ADMIN = "admin"

instead of

if role == "admin" {  

✅ Leverage Libraries

• Instead of reinventing everything, I use existing well-tested libraries.

---

6. Code Reviews: Learning From My Mistakes

The best way to improve code quality? Let others judge it mercilessly.

✅ Code Reviews Are Brutal (But Necessary)

• They expose bad habits and help me grow.
• I explain why I made certain choices in comments when submitting code.

✅ Learn from Feedback, Not Take It Personally

• Every critique helps me write better, cleaner code.

 Further Reading: How to Give and Receive Code Reviews

---

7. Naming Things Right (The Hardest Problem in Programming)

"Bad names make good code unreadable."

❌ Before:

func Process(d Data) Result {  

✅ After:

func CalculateInvoiceTotal(invoice Invoice) Amount {  

Good names make code self-documenting.

---

8. Writing Code That Speaks for Itself

Clean code doesn’t need comments to explain basic things.

❌ Instead of this:

// This function checks if the user is logged in  
func isLoggedIn(user User) bool {  

✅ I write:

func isUserAuthenticated(user User) bool {  

The function explains itself without needing comments.

---

9. Version Control: My Safety Net

I learned this lesson the hard way—after losing hours of work due to a bad edit.

✅ Commit Often, But Meaningfully

• "Fixed bug" is useless.
• "Fixed issue where users couldn't log in after session timeout" is helpful.

✅ Use Branches

• I never work directly on main—I create feature branches to avoid breaking the stable codebase. 

 Essential Resource: Git Best Practices

---

Final Thoughts: From Messy to Clean Code

Clean code isn’t about perfection—it’s about making future coding easier.

Every habit I developed—**clear names, simpler logic, handling failures, writing tests, avoiding repetition, learning from reviews—**makes coding a joy instead of a nightmare.

Now, when I open my old projects, I don’t see chaos. I see clarity. And that, to me, is the true power of clean code.

---

Want to Improve Further?

• 📖 Read Clean Code by Robert C. Martin
• 🛠 Try Refactoring
• 🎥 Watch Best Coding Practices Videos