More Code, More Problems
About a year ago, I wrote out some principles for web programming in PHP. I called it the MicroPHP Manifesto. The thing is, what I talked about wasn't really specific to PHP. So, I've decided to explore the concepts again in the context of the other languages I work with.
What follows are some principles I try to keep in mind.
Learn languages, not frameworks
My experience has been that I become a better, more versatile developer when I focus on learning a language first. Diving head-first into a full-stack, complex framework when I'm starting out has allowed me to build finished products more quickly, but it also becomes a detriment when I need solutions outside of the framework's scope. I often end up with a aoplug and praya approach to development, where I find a library or plugin that sounds like it will meet my needs, cross my fingers, and shove it in. That might get my app launched faster, but it makes stuff a lot harder down the road.
Additionally, learning a full-stack framework can be as complex as learning a new programming language. They often have complex architectures and nomenclaturesa-aparts that don't carry over to other frameworks and tools. I'd rather spend my time learning more about the language itself, knowing the skills that I learn will apply to anything I build in the language, no matter which libraries I use.
Build small things
Small units of code are good. The smaller it is, the easier it is to understand. It's harder to screw it upa-aand I screw stuff up a lot, so limiting that is really important.
So, I strive to build small modules of code with a single purpose, or at most a few closely-related purposes. They should be self-contained pieces that solve individual problems. These pieces then work together to solve larger, more complex problems.
With simpler, modular code, fixing bugs is easier, because I can look at an individual piece and see clearly what it's doing. And, if the modules are self-contained, testing my code is much easier.
Less code is better than more
To paraphrase Biggie Smalls, aomore code, more problems.a
I want to manage less code. Larger codebases get harder to manage. Searching across the codebase takes longer. Navigating through complex file structures takes longer. Tracing execution through dozens of files is hard. Keeping it all straight in my brain gets challenging.
Bigger libraries and longer code seem to overflow my brain buffer. I have trouble keeping track of code flow when the source gets too long, or when execution is jumping between several source files, and visual noise really affects me, too. This is why I love syntax coloring so much, and consistent whitespace really helps. I use the code folding feature in my editor a lot, just to hide things, so I can focus better on the task at hand.
I also want to support less code. I'm responsible for all of the code that my app uses, not just the stuff I wrotea-aevery single line of it. This means that bugs and security holes are my responsibility. How often do we see a WordPress or Drupal plugin get abandoned after a year or so? Am I sure I want to use a piece of code I don't really understand, when a year down the road I may have to fix an exploit in it?
This is not to say that I would never use code that I didn't writea-aI'd be hard-pressed to get much done that way, and frankly there are better programmers out there than mea-abut every line of code in my app matters, so I need to justify each one.
Create and use simple, readable code
I want code that is easy to understand. Understanding things quickly means getting stuff done faster. My time to productivity is shortened. My time to fix bugs is shortened.
I also want code that is easy to verify. My code should be testable, whether or not I get around to actually writing those
Truncated by Planet PHP, read more at the original (another 1335 bytes)