Breaking the rules to keep programming fun and experimental
Tags: webdev, html, css, php
Published: 2019-01-15 19:03:59

---
title: Breaking the rules to keep programming fun and experimental
description: A dive into how I sometimes deliberately ignore coding standards just to enjoy myself
published: true
tags: webdev, html, css, php
cover_image: https://images.unsplash.com/photo-1467139840664-96b244a66825?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1024&q=80
canonical_url: https://pretzelhands.com/posts/breaking-the-rules
---

<p><small>Photo by Ashim D’Silva on Unsplash</small></p>

> This post was originally published on [my personal blog](https://pretzelhands.com/posts/breaking-the-rules).

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](https://pretzelhands.com). 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`

```xml
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

![The first version of the post-fetching code](https://pretzelhands.com/assets/posts/rules-01.png)

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

```php
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!~