Some things that are important:

  • Black lives matter.
  • Stand with Ukraine.
  • Burn less carbon.
  • Burn the electoral college.
  • Be kind.

The rest will follow. Whatever you do, do it for the greater good.

Size Matters.

Tagged as:

And in programming small is nearly always better. One of the most common troubles I see in code I encouter is that the size of all the things has gotten too big. Methods run on for hundreds of lines. Classes contain dozens of methods.

The problem with big things in programming comes down to there being more that can go wrong. When something does go wrong, or somthing needs updated, there is more to wade through to figure out how to fix or update it without breaking what is already there.

From the patterns I see in PHP things, the tendency toward bigness often coincide with programmers who don't fully understand object oriented programming. Methods read like procedural PHP that uses classes as namespaced containers: a glorified file directory system, if you will. Even in procedural programs, though, I see files that run hundreds, sometimes thousands, of lines and create side-effects in multiple areas of the system.

So, what to do?

First, there is testing. I hear quite often that testing is too hard and takes too much time. And for code that is too big, that is likely true. But the objection doesn't apply for code that has not yet been written. For anything new, you can probably write tests first without too much trouble. Start there. If you start with tests, the code you write to pass the tests is likely to be smaller: you only write the minimum needed to pass the test.

Second, when you touch old code, refactor to smaller things. Michael Feathers' classic Working Effectively with Legacy Code is invaluable for this. If you're PHP, Paul M. Jones's Modernizing Legacy Applications in PHP is also your friend.

Meanwhile, as a general habit, my internal code bloat detector starts going off when:

  • a function runs more than a dozen lines,
  • a class has more than half a dozen public methods (excluding getters, but except for data objects, avoid getters; and you very rarely, if at all, need setters), or
  • a procedural file has more than 25 lines.

I've found chances are that anything larger is doing too much and should probably be refactored.