Coding philosophy

How I approach writing code.

After more than 20 years of development, I've learned that good code doesn't need to be complicated. In fact, I think some of the best code is the simplest.

Illustrative photography · cottonbro studio / Pexels

I follow a few principles:

Don't overengineer.

I believe in solving the problem in front of me, not building elaborate frameworks or abstractions for problems that may never exist. If a straightforward solution does the job well, that's usually the right solution.

<?php
// Don’t do this when the shorthand
// makes the intent harder to follow.
function getActiveCustomers(
  array $customers
): array {
  return array_filter(
    $customers,
    fn($customer) =>
      $customer->isActive
  );
}

Don’t do thisValid PHP, but the callback can hide the steps from a reader unfamiliar with it.

<?php
// Do this instead: keep it simple.
function getActiveCustomers($customers)
{
  $activeCustomers = [];

  foreach ($customers as $customer) {
    if ($customer->isActive) {
      $activeCustomers[] = $customer;
    }
  }

  return $activeCustomers;
}

Do this insteadStart with an empty list. Check each customer. Add the active ones.

Write code that's easy to read.

I like descriptive, obvious names for variables, functions, and classes. Ideally, the code should be simple enough that even a 12-year-old could follow the general idea. Clever code doesn't impress me nearly as much as clear code.

<?php
// Don’t do this: make readers
// guess what the names mean.
function check($u, $p): bool
{
  $x = $u->id === $p->ownerId;
  return $x;
}

Don’t do thisShort names hide the permission being checked.

<?php
// Do this instead: name the intent.
function canEditProject(
  $user,
  $project
): bool {
  $isProjectOwner =
    $user->id === $project->ownerId;

  return $isProjectOwner;
}

Do this insteadThe names explain who can edit the project.

The 30-second rule.

When another developer looks at a function, they should be able to understand its purpose in about 30 seconds. A complex algorithm or business rule may take longer to understand in detail, and that's okay. But the intent should be clear. If it takes several minutes just to figure out what a function is trying to do, there's probably a simpler way to write it.

<?php
// Don’t do this: bury a simple rule
// inside layers of conditions.
function canRefund($order): bool
{
  if ($order->status === 'paid') {
    if ($order->total > 0) {
      if (!$order->refunded) {
        return true;
      }
    }
  }
  return false;
}

Don’t do thisThe reader has to trace nested conditions to understand the rule.

<?php
// Do this instead: make the
// reasons for saying no obvious.
function canRefund($order): bool
{
  if ($order->status !== 'paid') {
    return false;
  }
  if ($order->total <= 0) {
    return false;
  }
  if ($order->refunded) {
    return false;
  }
  return true;
}

Do this insteadEach guard clause explains why an order cannot be refunded.

Don't refactor just for the sake of refactoring.

If existing code works and can be extended cleanly, I prefer to build on it. I don't believe in rewriting things just because there's a newer pattern or a more fashionable architecture. I also make small improvements as I work when they make the code easier to understand or extend. I don't need to wait for a design to become a problem, but I do want a clear benefit and a manageable risk.

<?php
// Don’t do this just to replace
// a working loop with shorthand.
function subtotal(array $items): float
{
  return array_reduce(
    $items,
    fn($total, $item) => $total +
      $item->price * $item->quantity,
    0.0
  );
}

Don’t do thisThis version works, but a different style alone is not a reason to rewrite existing code.

<?php
// Do this instead: keep the clear,
// working code when it fits the task.
function subtotal(array $items): float
{
  $subtotal = 0.0;

  foreach ($items as $item) {
    $subtotal +=
      $item->price * $item->quantity;
  }

  return $subtotal;
}

Do this insteadKeep the existing loop when it is clear and easy to extend. Refactor when there is a concrete benefit.

At the end of the day, I believe good code should be easy to read, easy to maintain, and easy for the next developer to work with. It doesn't need to be clever. It needs to work.

More about me Explore my work

Let’s talk about your project.

Tell me what you’re building or what needs fixing.

Start a conversation