Front End Code Etiquette
One of the most interesting parts of working as a web developer comes from making a decision on how to organise code depending on a particular project or problem.
There are multiple ways to do the same thing, and there's not necessarily a wrong or a right answer for every situation.
Take namespacing for example. As my previous post showed, there are multiple ways to declare methods within your namespace and none of them are incorrect. We all have opinions on how code should be structured and we all have our own ideas of what constitutes acceptable coding rules.
Unfortunately sometimes I encounter a problem that irritates me, and it happens much more often than I would like. It can be summarised in the following sentence:
If you are working on someone else's code, respect their coding standard guidelines.
It is so common to see code which has had contributions from multiple developers use multiple coding styles. It makes untidy code look even messier and it reduces maintainability.
Sure, you may prefer to lay your code out in different way, but unless there is a good reason for changing it (and 99% of the time, there isn't) stick with what conventions are already there. Some particular examples:
- CSS classnames that change between conventions. For example, styles that are all in lowercase with hypens, except for one area where underscores and/or camelCase is used.
- Creating a new namespace for code that belongs in the existing JavaScript namespace.
- Adding images, CSS or JavaScript to a completely different folder to where the rest are stored - or in to the root.
- CSS styles blindly added to the end of a stylesheet, breaking the perceived structure of the code - or styles added in to the reset styles area.
- Indenting of CSS styles or brackets.
- A extra CSS or JavaScript file added for reasons logic cannot understand.
- And my personal favourite - finding a single extra function that should belong in a namespace sitting outside in the global scope.
For me, there is nothing worse than seeing a project where everyone on the team is using a particular standard, and someone else isn't. As far as I'm concerned, this person has poor attention to detail, this person is a code vandal. I like tidy, maintainable code. I shouldn't be able to view source on your code and be able to tell it was written by multiple people.
So next time you work on an existing project, take the time to read through the code layout that already exists and ask yourself "how can I integrate the code I write seamlessly in to this project?".
Be considerate not Taz.
More Blog Posts
All Roads Lead to React Native
For a startup, choosing the wrong app technology can cost you millions in burn and years of wasted engineering time.
All the Small Things
In a startup it's important to reduce friction. The main asset available to you is to go fast. If you can't do that, you won't beat the competition.
Observability with Slack Workflows
I recently needed to keep an eye on a third party's rate limit during a product launch, and Slack Workflows seemed like a nice solution to alert me to issues. Let's take a look at how it worked.
Peacetime vs Wartime
Your monolith is buckling under heavy traffic growth. The quick fix is to beef up the server through vertical scaling and buy yourself six months. The right fix is a four month microservices migration that will either save the company or kill it if you miss the deadline. Meanwhile your $2m client is demanding new features or they'll go elsewhere.