6 Ways to be a Thoughtful Coder

Image credit: Pixabay

As much as programming can be isolating at times (often as a matter of choice), it doesn’t place you in a vacuum. If anything, it connects you to the rest of the world. Whether as part of a collaborative project or when used for inspiration or guidance by another coder seeking a solution, the code you write can have a long and storied career of its own.

Furthermore, you’re more often than not going to be working as part of a team, which requires you to share information, target common standards, and generally support your colleagues as they support you in return. There’s no room for the kind of selfish thoughtlessness that you can get away with when hacking away at projects in your spare time.

By being a thoughtful and generous coder, you can increase your peace of mind, get along better with your teammates, know that you’re helping out the programming community, and simply establish better habits in general. So how can you do it? Let’s take a look at 6 ways:

Aim for elegant code

Brevity isn’t always possible, and sometimes the only solution you can find will run to hundreds of lines and include numerous awkward workarounds. That’s understandable, and in the end, the main thing that matters is that your code achieves its purpose. However, you should always do your best to achieve elegance — it’s a big part of coding well.

By this, I mean that you should try to solve the problem in as few lines as possible, as quickly as possible, and using as few resources as possible. There’s every chance that your solution will need to adapted at some point down the line, and that will be so much easier to achieve if it doesn’t depend on ad-hoc shortcuts and clumsy redundancies.

Provide version tags

As time goes by, programming languages change significantly. New features are introduced, old tags are revised, and compatibility is far from assured. This isn’t generally a big problem because there’s always reasonable continuity between adjacent versions, but it can be a big problem when systems aren’t updated for several years (or when the chunk of code someone needs to solve a problem was written 8 years prior in unclear circumstances).

This is why version tagging is so useful. When someone needs to trawl through your code to parse it and figure out how to adapt it, being able to see at a glance which parts were written using which language versions will make their task so much easier — they’ll be able to find the code migration tools they need right away instead of laboriously checking through every line for now-unsupported tags.

Use consistent formatting conventions

Everyone has personal formatting preferences. Some people like to head to new lines after opening brackets, while others like to keep things tidied on single lines (unusual, but it can happen!). Some use underscores to delineate multi-word entities, while others use camelCase. Some indent lines with tabs, others with spaces. This is totally fine: go with your preference.

However, make certain that you pick your formatting preferences and stick with them. Don’t go from underscores to camelCase and back to underscores in the space of a paragraph (or at all). Don’t keep tidy single lines in one section only to space everything out massively in the next. That kind of inconsistency not only looks horrible and makes code much harder to parse, but it also causes havoc when it comes to searching.

Name entities logically

When you first look at unfamiliar code, your brain searches for some kind of foothold to start processing what’s going on, looking for familiar terms and conventions you can use to puzzle through the basic functionality. Standards aren’t just for cross-platform compatibility — they’re also vital for people trying to read code.

When you realize late in the day that you need another variable to get your solution working, and you only have ten minutes left before you can leave, it can be tempting to take the shortcut of just using a random string of letters and numbers for the variable name. You might think there’s no harm in it as long as it works, and that’s mostly true. But when someone then needs to review your work, it might take them a while to puzzle through the exact purpose of that variable — if you’d simply given it a meaningful name, there would have been no issue.

Document everything you write

It’s quite easy to pass the buck when it comes to documentation. If you’re playing a large role in the ongoing development of a large system, you might think that documentation isn’t really necessary because you know what you’ve been doing, and if you’re just contributing occasional pieces to a larger development chain, you might think that you’re insufficiently important. But documentation is important for code sharing, implementation, and adaptation, and even if previous coders haven’t documented their work, you should document yours.

It doesn’t need to be painstaking: just explain what problem you needed to solve, how you came up with your solution, and how you implemented it. It’s become quite popular for entrepreneurs to buy existing websites now, and you can be sure that a site with well-documented features will be more valuable. You even find this useful if you need to revise it years later, because you’re not always going to remember what you were thinking!

Know how your code is going to be used

Ethical considerations are becoming increasingly significant in the coding world, as individuals and corporations alike come to question what exactly their code is being used for. Even if your code is for a fully-justified project and making it available online will help a lot of well-intentioned developers, do you know how else your data might be used?

Think about the impact of GDPR this year, and how people have become distrustful of organizations that seem all too willing to exploit their data. I’m not saying that you should quite a project if you have ethical concerns about it (you have bills to pay, I’m sure), but should you ever want to volunteer some time to a project, make sure that it’s something worth your time first, and that it won’t put your code to bad use.


Victoria Greene is an ecommerce marketing expert and freelance writer who can’t stand it when code lacks internal consistency. You can read more of her work at her blog Victoria Ecommerce.

#codango #developer #development #coder #coding

We're happy to share this resource that we found. The content displayed on this page is property of it's original author and/or their organization.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*