Photo by Ashim D’Silva on Unsplash
This post was originally published on my personal blog.
You probably have processes at work. Style guides for writing your code. Unit tests and integration tests verifying each piece of functionality. Best practices established in the project over a commit history in the thousands. The sacred rules established in your company and by the programming community at large. And following those rules is important for a product used by potentially thousands or millions of users.
But sometimes, in your personal projects, you should try throwing the rules out of the window. Just chuck them out and play around! One such example is the code behind my blog. It's written in PHP without a framework of any kind. It's a loose collection of loose PHP files with a bunch of rewrite rules holding it together. It's basically like a non-polished version of Jekyll.
Here's what the folder structure looks like using tree
blog
├── bootstrap.php
├── composer.json
├── composer.lock
├── lib
│ └── Post.php
├── ps
│ ├── 2019-01-02-coloring-terminal-text.md
│ ├── 2019-01-03-non-obvious-behaviors.md
│ ├── 2019-01-04-command-line-flags.md
│ ├── 2019-01-05-bringing-your-entire-infrastructure-down.md
│ ├── 2019-01-07-jinx.md
│ ├── 2019-01-09-how-i-got-into-freelancing.md
│ ├── 2019-01-12-mentoring-junior-team-members.md
│ ├── 2019-01-14-building-responsive-email-with-mjml.md
│ └── 2019-01-15-breaking-the-rules.md
├── public
│ ├── assets/ (images etc.)
│ ├── blog.php
│ └── index.php
├── vendor/ (dependencies)
└── views
├── base.mustache
├── blog.mustache
├── listing.mustache
└── partials
├── about-me.mustache
├── description.mustache
├── header.mustache
├── newsletter-form.mustache
└── title.mustache
The public folder is what gets exposed. The ps folder contains all of my posts written in Markdown with frontmatter. The lib folder holds the class responsible for loading posts.
Internally a URL like https://pretzelhands.com/posts/jinx gets rewritten to https://pretzelhands.com/blog .php?slug=jinx. I then search the files to match the correct one based on the slug. I parse the post date from the title. All of that happens in a Post class. Before that the code was directly in blog.php along with some nasty mixed up HTML.
Here's what that looked like
Is it ugly code? Unbelievably so. Was it fun to write? You bet! The entire blogging system was running in an hour or two on a Sunday before going back to work. I didn't want it to be pretty, I just wanted to get it out there. And whenever some code becomes unbearable to look at some selective refactoring happens.
And I love hacking on this thing. I bolt on some code, upload it to my server and call it a day. There's some globals running wild, there's code duplication, there's all sorts of stuff I would get yelled at for during a code review. But no one will ever see the code for my little blog, so I'm totally okay with doing this. It's my own messy little playground. I keep adding to it and see what sticks.
So if you're ever working on a small project of your own that isn't intended to be The Next Big Thing™, why don't you just go all out and write code as if you're throwing color at the wall? It's incredibly therapeutic, I tell you!
Here's an example from a project didn't see the light of day
require_once('../../server/bootstrap.php');
use Respect\Validation\Validator;
use Carbon\Carbon;
$database = getDatabaseConnection();
$emailValidator = Validator::email();
if (!isset($request->email) || !$emailValidator->validate($request->email)) {
sendResponse([
'error' => true,
'errors' => [
'Please provide a valid email for logging in.'
],
'errorFields' => [
'email'
]
], 400);
}
There's no standardization to any of this. The sendResponse function was a little wrapper that just sent a few headers, serialized the array into JSON and echoed it all. $request is just the STDIN PHP provides wrapped in json_decode It's beautiful in its ugliness.
Disclaimer
This does not mean I think you should write production code as if you're some abstract artist and ignore all rules and conventions at work. Those conventions usually have good reasons behind them. But I feel like if you're programming for your own enjoyment it helps to be more creative and experimental. To get rid of rigid structures. Who knows, maybe you find something you really like and can refine and improve.
So don't go around and tell people that Richard gave you the permission to write spaghetti code. 😁
Enjoy!~
Top comments (1)
Sometimes ugly can be beautiful in its own way. Breaking things and experimenting is a great way to scratch that creative itch!