Adding Personal Flair to Your Code

Jan 9, 2017

I’ve been thinking recently about the naming conventions I use while coding, and I noticed I tend to follow pretty strict naming standards so I don’t have to put much thought into picking a name. While standards are usually good for readability, too many standards makes code seem robotic. Since (most) humans are not robots, this can actually have a negative effect on readability. Furthermore, it may save a bit of time in the short term to just follow a standard so you don’t have to think about how you’re naming variables or functions, but it seems to me that limiting the amount of thought you put into your code isn’t the best way to maximize your efficiency as a programmer.

Before learning about code style standards and naming conventions, I often wrote code more like a story than a list of instructions. Okay, so it was more like a blob of text with no particular rhyme or reason to it, but occasionally I would get a bit creative with variable names or parameters, and it was typically easier to look back at that code and recall how it worked. Not because it was any less of a mess, but because it was more engaging to read through. Some standards, like consistent indentation or camel/snake case variable names, should take precedence over personalization. But if seeing a punny variable name keeps you from spacing out while reading through code, either because you remember having fun writing it or because you enjoy reading it, I think it’s worth having.

Finding a way to make your code fun to read for you and others is also a good way of keeping you on your toes while you’re writing it. I think most programmers would agree that writing code is not something you should be able to phone it in on. It can be easy to zone out when you’re doing something monotonous, but you can’t write effective code if you’re not thinking about it when you write it. Suppose you were writing software that writes software. In order to make this software efficient, you would probably want it to write code that is standardized in every way possible. It can be tough as a programmer to remember that people aren’t software, but people are not software. So while a computer doesn’t mind parsing through monotonous, over-standardized code, (most) programmers will have a hard time staying focused when reading that same code.

Maybe you’re just as happy writing code that’s straightforward and minimal, and that just comes down to personal preference. If you can make writing code more enjoyable without negatively affecting readability or performance, why wouldn’t you? I’m not saying every variable name should be some elaborate, well thought-out joke, but if you can make coding fun, you should. Life’s too short to write dull code!

RECENT POSTS

The Agile Manifesto in Practice: Part 1

The Agile Manifesto in Practice: Part 1

  How Sourcetoad Values People Over Process The software development process can involve a lot of uncertainty for both development teams and clients alike, especially in the early phases of a project. How can the long-term vision of an application be balanced...

What to Consider When Building HIPAA-Compliant Software

What to Consider When Building HIPAA-Compliant Software

In 1999, the Department of Health and Human Services (HHS) passed the Health Insurance Portability and Accountability Act (HIPAA) as a measure to protect personal health information (PHI) and allow people control of their healthcare records. The HITECH Act was enacted...

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

The Evolution of Buy Now, Pay Later in eCommerce: Part 2

In Part 1, we talked about the rapid growth of Buy Now, Pay Later (BNPL) and discussed its expansion across industries. In Part 2, we will consider how impending regulation may shake up the short-term lending space.   Impending Regulation of BNPL While consumers...