Skip to main content
ANVISoftware Solutions
Lesson 15 of 15Beginner12 min

Clean Coding Habits

By the end of this lesson

Adopt a few habits early that keep code readable as it grows, and know which advice to ignore.

Code is read far more often than it is written. The person reading it is usually you, several months later, with no memory of why you did it that way.

These habits cost almost nothing to adopt now and are noticeably harder to retrofit later.

Name things for what they mean

Same logic, different readability
C#
// Hard to follow
if (d > 30 && s != 2)
{
    p(c);
}

// Clear
if (daysOverdue > 30 && status != AccountStatus.Closed)
{
    SendFinalReminder(customer);
}
  • Nothing about the structure changed. The second version simply says what it is doing.
  • Good names remove the need for most comments, because the code already explains itself.

Comment the why, not the what

C#
// Pointless — the code already says this
// add one to the counter
counter++;

// Useful — explains a decision the code cannot convey
// Suppliers send dates in local time with no offset, so we treat them as
// IST before converting. Confirmed with the supplier integration team.
DateTime supplierDate = TimeZoneInfo.ConvertTimeToUtc(rawDate, indiaStandardTime);
  • The first comment restates the code and will eventually contradict it when the code changes.
  • The second records knowledge that is not in the code at all, which is exactly what comments are for.

Habits worth forming now:

  • Keep methods short enough to see at once — if you are scrolling, consider splitting
  • One method, one job. If the name needs "and", split it
  • Avoid unexplained literal values. 0.18m means nothing; taxRate means something
  • Be consistent in formatting and naming within a file, then across a project
  • Delete code you are not using. Version control remembers it; your file does not need to
  • Handle the failure case near where it can occur, rather than far away

One last point. You will look back at code you wrote a few months ago and find it clumsy. That is a sign of progress, not of earlier incompetence. The aim is not to write perfect code now, it is to write code you can improve later.

Summary

  • Name things for meaning; good names remove the need for most comments
  • Comment the why, never the what
  • Keep methods short and single-purpose, without fragmenting simple logic
  • Treat clean-code advice as heuristics, and apply judgement rather than rules

Practice

Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.

Try it yourself

Try it yourself

Rewrite this so it explains itself, without changing behaviour:

if (x.s == 1 && x.b > 0 && DateTime.Now > x.d) { Process(x); }

Show solution

Name the entity, name the conditions, and replace the magic number with something meaningful. The logic is untouched; the intent is now visible.

C#
bool isActive = invoice.Status == InvoiceStatus.Active;
bool hasOutstandingBalance = invoice.Balance > 0;
bool isPastDueDate = DateTime.UtcNow > invoice.DueDate;

if (isActive && hasOutstandingBalance && isPastDueDate)
{
    ProcessOverdueInvoice(invoice);
}

Knowledge check

Nothing is recorded and there is no score. The explanation appears either way.

What is the most useful thing a comment can record?

Saved in this browser only.

End of the published lessons

That is everything written so far in Programming Fundamentals

More lessons in this course are on the way. In the meantime, the course page shows the full roadmap, and the projects are the best way to consolidate what you have covered.