Hard Stances on Arbitrary Things - My Preferred Coding Conventions

Bring up coding conventions if you want to quickly turn a roomful of friendly developers into a dangerous collection of crazy people that are out for blood. It's fun! Try it at parties!

Here is an every-growing collection of my preferred coding conventions, and why I'd fight to enforce them.

Curly Braces On a New Line

public int methodName()  

This is probably one of the most derisive coding conventions that I feel most strongly about. Unlike what Google would say, I suggest putting the opening brace of a nonempty block of code on a new line. For me, this makes code more readable as nesting increases, as it gives some extra built-in whitespace to separate lines, and, in combination with tabs, gives a very clear delineation of context.

Tabs over Spaces

Tabs are a single character and their display is configurable in your editor! If you prefer your tabs to be 8 full spaces, you can happily configure your tabs to be displayed that way, and us normal people in 4-spaces-per-tab world can use the exact same file and configure our editors to our own liking. In short, tabs give everyone what they want. With spaces, you're locked in to whatever decision the original developer of a file made on how many spaces should be in a tab, and as time and coding conventions change, that's just unneeded baggage.

Don't Call Yourself a Programmer?

This was originally published on an older version of this blog, when my job title was "Java Developer". Now, my 'official' title is "Development Manager", and my point here still holds true: What I do is what's important (lead a team, architect software), not the words on my business cards.

I've gone through several iterations on what I tell people I do. In college and grad school, I fancied calling myself a 'computer scientist.' This was mostly in jest, playing on the joke that anything calling itself a science probably isn't, but it also weirdly seemed to work in the world of academia. When I had to be serious, I would tell people I'm a programmer, or simply "I write code". Now, my job title at work is developer, and that's the term I gravitate towards now. When I'm asked what I do for a living, I usually answer "I'm a software developer." This isn't, however, because I think "developer" is inherently more important sounding than programmer, or coder, just that I've found it to be the easiest explanation for people, without requiring more questions.

Not everyone agrees that developer and programmer are interchangeable though. Back in 2011 Patrick McKenzie wrote a blog post giving career advice and included the suggestion to not call yourself a programmer.

I mostly agree with his argument against the title. I've noticed that the term 'programmer', for better or worse, has a stigma to it. It can bring to mind visions of infinite monkeys on infinite typewriters. The fear is that describing yourself as a programmer might make someone think that the software got written, but it wasn't actually designed. There was no finesse, no higher craft, no forethought. You slapped something together, probably from a spec written by an actual developer.

But in reality, that's goofy, right? Often what you're called really has nothing to do with your development skills. Just because someone has a fancy, overwrought job title doesn't mean they can actually implement FizzBuzz. There are lots of ways to get job title, and pure development merit it might not always be.

In reality, many programmers/developers/engineers get far too worked up over job title (and boy do they get oh so worked up). This is true in your profession, and even more true in life in general:

Your worth isn't based on what you call yourself, your worth is derived from your actions.

You say you're a software engineer, and have the resume to back it up? Rad. You've got a killer resume but would rather just be called a programmer? That's rad too. In the end it's just a word, and what you do is what truly matters.


Java, and in turn, Java developers, love camel case. Camel case, of course, is the style of creating compound words in which each individual word starts with a capital letter (like the humps on a camel). So, for example:

  • DiceGame
  • RandomEventGenerator
  • GraphicsProcessor

When creating a variable name, you typically don't uppercase the first letter of the first word. Still pretty simple, giving you things like myVariableName or rawUserInput.

Camel case goes awry, however, when you start to throw acronyms into the mix (and we computer types certainly love our acronyms). Even Java itself is inconsistent when dealing with camel casing acronyms, just look at these HTTP related classes from the Java API:

  • HTTPBinding
  • HttpContext
  • HttpCookie
  • HTTPException
  • HttpExchange
  • HttpHandler
  • HttpURLConnection

The natural inclination is to leave the acronym in all caps, like HTTPBinding. Two acronyms together makes that a mess though: HTTPURLConnection.

So, the best solution is to treat all acronyms as regular words, and apply all the normal camel case rules to them, giving us HttpBinding and not HTTPBinding, and HttpUrlConnection and not HttpURLConnection. This is also quite convenient when you need to create a local variable with a lowercase fir letter: httpBinding makes far more sense than hTTPBinding.

We Are Ghost

A new blogging platform, and a new excuse to kick the tires. This is Ghost, the new hotness amongst internet hipsters, trendier nerds, and anyone with a Macbook and a pair of skinny jeans. I'd assume some people I didn't just offend use it as well, but I can't be sure.


I'm a WordPress man. Have been for years. Yet, in all my years of using WordPress, I never really liked it. It has greatly improved over time, but it always comes down to being clunky, bloated, resource intensive, and finicky. However, it was easy to set up, and you'd have a decent looking site in a short amount of time. WordPress started as a blogging platform and along the way became a jack-of-all-trades full blown CMS, which is great when you need a CMS... and in the way when you just want to blog.

I didn't understand what Ghost was for a long time. I'd seen the talk about it, but their homepage was pretty cryptic, initially. Plus, there was no demo accessible without signing up. Internet Commandment #1 states Thou Shalt Sign Up For a Website Only as a Last Resort, and With Much Grumbling and Gnashing of Teeth. I'll, uh, give you the rest of the commandments after lunch.

Anywho, I ignored Ghost and got into Jekyll instead. Jekyll is cool. It uses Markdown (who doesn't love Markdown) and generates a static site. With that, you can do very cool things, like hosting the site on GitHub Pages (This very site lived on GitHub Pages for a long time). Since your site is on GitHub, your blog becomes a git repository, so each blogpost is a commit, and readers can even help fix errors via pull requests. How slick! Except, until it isn't. Having to start a development server to simply preview your blogpost is tiring, and makes writing while traveling, or on your iPad or phone, a real challenge. Having to commit blog drafts (or rely on local storage) became a hassle. Eventually, all the benefits of Jekyll also became the biggest downfalls to me.

So, in tearing down an existing VPS on Digital Ocean, I noticed that they had added the ability to install Ghost as an application. I figured there was never going to be an easier way to check it out, so I jumped in... and I'm pretty smitten.

I Ain't 'Fraid of no Ghosts

Ghost originated as an idea from John O'Nolan. I love the tone of that page. Basically, "this would be cool, here's the pitch, who wants to work with me to make it?" The idea is to basically strip away everything that makes WordPress "more than a blog" and perfect the "just a blog" part. A Ghost site is pretty darned barebones. Likewise, the admin page is almost shockingly simple. You're initially presented with a list of blog posts, and you can edit them or create a new one. Aside from a few meager settings, that's it.

And that's awesome.

Ghost has great, Markdown based writing interface, and dead simple publishing. It strips away all the crap and gets straight to writing. That means it isn't a Swiss Army Knife, able to effectively deliver any possible type of website, but for making personal blogs, it is probably the best option today.

Incorpo-realizing the Dream

I don't want many improvements to Ghost. Maintaining this barebones setup and approach is ideal for what Ghost is striving to do. There are only a couple minor things I'd like to see expanded up.

The first is theming. It is my understanding that creating a Ghost theme is a pretty straightforward, pleasant experience. However, in self-hosted Ghost, switching to a new theme is not. You have to track down the theme (usually downloading zip of a GitHub repository), then upload the contents via FTP to your server directly. That's cumbersome, and some users wouldn't even know where to begin. I'd love to see a theme uploader/manager added to Ghost, to fully embrace the open theming concept they seem to want to foster.

The second thing I'd like to see improved upon is image uploading. It exists for your logo and cover image, but inline images on individual blog entries, no dice. I understand this is a slippery slope towards WordPress overbearing-ness, but I think it can be handled correctly. Even just giving some visibility to your images folder on your server, and letting you upload via the user interface, would be a welcome addition.

Other than that, I'm extremely pleased with my time with Ghost so far, and I'm excited to see the community grow with increased adoption.