Standard Practices and Conventions

Introduction: The Professional Developer's Playbook 📖

Writing code is only half the battle. Professional developers follow industry-standard practices that make teams more productive, code more maintainable, and collaboration seamless.

Think of these as the "traffic rules" of programming—everyone follows them so we can all work together smoothly!

Git & GitHub Workflow Best Practices 🌳

Branch Management

┌─────────────────────────────────────┐
│  One Ticket = One Branch = One PR   │
└─────────────────────────────────────┘

The Golden Rules:

✅ One branch per ticket/issue

• Keep work isolated and organized
• Easy to review and track changes

✅ One PR (Pull Request) per ticket

• Clear scope for reviewers
• Simple to approve or reject

✅ Delete merged branches

• Keeps repository clean
• Prevents confusion

Visual Workflow:

main ●────●────●────●
          ↓         ↗
feature   ●───●───● (merge, then delete)

Pull Request (PR) Best Practices

Practice	Why It Matters
Create PRs early	Get feedback sooner, reduce conflicts
Mark as draft if WIP	Shows work is in progress
Merge PRs quickly	Reduces merge conflicts
Fix your own conflicts	PR author knows the changes best
Discuss code in PRs	Keeps all context in one place

PR Workflow Timeline

Day 1: Start work → Create draft PR
Day 2: Continue work → Update PR
Day 3: Finish work → Mark PR ready
Day 4: Address feedback → Get approval
Day 5: Merge PR → Delete branch ✅

Testing Before Submission 🧪

The Professional Standard:

❌ Untested code = Amateur work
✅ Tested code = Professional work

Before creating a PR, always:

1. ✅ Test your code locally
2. ✅ Check for errors and edge cases
3. ✅ Verify it works as expected
4. ✅ Run automated tests (if available)

Never Do This

// Writing code
git add .
git commit -m "fix"
git push  # ❌ Without testing!

Why it's bad:

• Wastes reviewers' time
• Shows lack of professionalism
• May break production
• Creates technical debt

Communication Best Practices 💬

Async communication is king! Use tools like Slack, Discord, or email instead of always demanding immediate responses.

Understanding Communication Types

Two main types:

Synchronous Communication (Real-Time) ⏱️

Real-time conversation where both parties are present.

Person A: "Hey, can you help me?" ──→ Person B
Person A: ←── "Sure, what's up?"   Person B
         (Immediate back-and-forth)

Examples:

• 📞 Phone calls
• 🎥 Video meetings
• 💬 Live chat (expecting instant reply)
• 🤝 In-person conversations

Pros:

• Quick decisions
• Immediate clarification
• Personal connection

Cons:

• ⚠️ Interrupts work (breaks flow)
• ⚠️ Both must be available
• ⚠️ Can be inefficient

Asynchronous Communication (Delayed) ⏳

Communication where responses come later, no real-time requirement.

Person A: "Can you review my code?"
              ↓ (sent)
         [Time passes...]
              ↓ (when Person B is free)
Person B: "Reviewed! Looks good."

Examples:

• 📧 Email
• 💬 Slack/Discord messages (no urgency)
• 🐛 GitHub PR comments
• 📝 Documentation

Pros:

• ✅ Doesn't interrupt flow
• ✅ Time to think through responses
• ✅ Works across time zones
• ✅ Creates written record

Cons:

• Slower for urgent issues
• May delay decisions

Why Async Is King 👑

In modern development teams:

Sync Communication = Exception (emergencies only)
Async Communication = Default (99% of work)

Best practices:

1. Default to async (Slack, email)
2. Use sync only when truly needed (emergencies, complex discussions)
3. Respect "Do Not Disturb" status
4. Document decisions in writing

The "Default to Async" Rule

Before scheduling a meeting, ask:

• Can this be a Slack message? ✅
• Can this be a PR comment? ✅
• Can this be an email? ✅
• Does this truly need real-time discussion? (Rarely!)

You'll save hours every week!

Naming Conventions: Code That Reads Like English 📝

Good names = Self-documenting code!

1. Use Descriptive Names

Your code should explain itself without comments.

// ❌ BAD: What does this contain?
const data = [1, 3, 5, 7];
const my_list = [2, 4, 6, 8];

// ✅ GOOD: Clear purpose!
const oddNumbers = [1, 3, 5, 7];
const evenNumbers = [2, 4, 6, 8];

Functions too:

// ❌ BAD: Get what? From where?
function get() {
  return { name: "John Doe" };
}

// ✅ GOOD: Instantly clear!
function getUserFromDatabase() {
  return { name: "John Doe" };
}

2. Nouns for Variables (Things) 🏷️

Variables are data/things, so use nouns.

Variables = Things (nouns)

Examples:

// ❌ WRONG: Verbs as variables
const getCount = 42;      // Sounds like a function!
const calculateTotal = 100; // Confusing!

// ✅ RIGHT: Nouns for data
const count = 42;
const total = 100;
const userProfile = { name: "Alice" };
const shoppingCart = [];

More examples:

Bad ❌	Good ✅	Why
getData	data	Variable is the data itself
getCount	count	Variable holds the count
calculatePrice	price	Variable is the price value

3. Verbs for Functions (Actions) ⚡

Functions do things, so use verbs.

Functions = Actions (verbs)

Common verb patterns:

// ✅ GOOD: Action verbs
function getUser() { }      // Retrieves
function createOrder() { }  // Creates
function updateProfile() { } // Updates
function deleteComment() { } // Deletes
function validateEmail() { } // Validates
function calculateTotal() { } // Calculates
function formatDate() { }    // Formats

Bad vs Good:

// ❌ WRONG: Noun as function name
function user() {
  return { name: "John" };
}

// ✅ RIGHT: Verb shows action
function getUser() {
  return { name: "John" };
}

Visual Pattern:

Variables:    user, count, price, items
             (nouns - things)

Functions:   getUser(), addItem(), calculatePrice()
             (verbs - actions)

Quick Reference Table

Type	Pattern	Examples
Variable	Noun	user, count, orderList, isActive
Function	Verb + Noun	getUser(), createOrder(), updateCart()
Class	Noun (capitalized)	User, ShoppingCart, DatabaseConnection
Constant	UPPERCASE_NOUN	MAX_USERS, API_KEY, DEFAULT_TIMEOUT

Minimize Variables: Less is More 🎯

Every variable adds complexity. If a variable is used only once, skip it!

Why Fewer Variables Matter

More variables = More state = More complexity = More bugs

Each variable you create:

• ❌ Adds mental overhead
• ❌ Increases state to track
• ❌ Creates potential for bugs
• ❌ Makes code harder to refactor

Example: Unnecessary Variable

// ❌ BAD: Temporary variable used once
const persons = ["John", "Jane", "Bob"];
const firstPerson = persons[0];  // Only used once!
console.log(firstPerson);

// ✅ GOOD: Use directly
const persons = ["John", "Jane", "Bob"];
console.log(persons[0]);

When It's OK to Create Variables

Create variables when they:

1. Improve readability

// ✅ GOOD: Complex calculation explained
const taxRate = 0.08;
const subtotal = 100;
const taxAmount = subtotal * taxRate;
const total = subtotal + taxAmount;

2. Are reused multiple times

// ✅ GOOD: Used 3 times
const currentUser = getUserFromDatabase();
logActivity(currentUser);
updateSession(currentUser);
sendWelcomeEmail(currentUser);

3. Make debugging easier

// ✅ GOOD: Can inspect intermediate value
const rawData = fetchFromAPI();
const processedData = transformData(rawData); // Can log this
return processedData;

More Examples

// ❌ BAD: Unnecessary intermediate variables
function calculatePrice(item) {
  const basePrice = item.price;
  const tax = basePrice * 0.1;
  const shipping = 5;
  const total = basePrice + tax + shipping;
  return total;
}

// ✅ GOOD: Direct calculation (still clear)
function calculatePrice(item) {
  const tax = item.price * 0.1;
  return item.price + tax + 5;
}

Key Takeaways 🎯

Remember:

✅ Git Workflow

• One branch per ticket
• Test before submitting PR
• Merge quickly, delete branches

✅ Communication

• Default to async (Slack, email)
• Use sync only when necessary
• Document decisions

✅ Naming

• Descriptive names always
• Variables = Nouns (things)
• Functions = Verbs (actions)

✅ Code Quality

• Minimize variables
• Test your code
• Keep it simple

Following these practices makes you a professional developer! 🚀