Picture it: the initial development for one of your more critical projects has just wrapped. You made the decision to place the project’s implementation with a smaller firm or freelancer as a cost saving measure. Maybe your website or application already had a rough initial design that was handled by the team you cultivated for the job. Either way, this first major hurdle is complete, and for the time being it seems as if everything was accomplished according your requirements.
…Until there’s a bug. It can be something cosmetic and superficial – an improper alignment or a poor rendering of an asset. Or it can be something critical – for example, throughout thousands of lines of code there is a single semi-colon missing, and all of your pages are broken or a visual mess. But as you make the attempt to resolve the issue in-house, before having to put aside another handful of capital for repairs, the code opens up and you see a wild, illegible, undistinguishable mess of programming.
The individual or team that you hired for the job are “code cowboys,” programmers who don’t follow the best practice etiquette for structuring their code. The job gets done, but it’s completed as more of a “hack” than as a well-polished machine. The code is so poorly put together that you can’t modify it yourself, and it will take another team days just to navigate themselves through the clutter. Instead of a neatly organized collection of machine language, you’ve got a plate of spaghetti; you can find one end, but navigating it to it’s conclusion involves a mess in between. You have to return to the source of the disarray, as they are the ones who understand the code, and the situation only becomes worse.
When selecting a freelancer, small firm, or even a large-scale operation to handle the development needs of your business, it is always a fantastic idea to screen them by asking for portfolio references to their work. You can get under the hood with what they’ve done in the past, and inspect it for a few of these major best coding practices.
Proper Indentation Aids Readability
The value of proper code indentation can’t be over exaggerated. When you’re working with a dozen lines of code, indentation may be trivial. But when you’ve got several hundreds, or thousands, of lines staring you in the face, none of which are properly aligned with one another, it becomes difficult to make sense of what belongs where.
Indentation is the first and simplest way of maintaining organization and structure throughout your code.
Each new line of code may fall on the same indentation as the previous, unless it belongs to the previously initiated function or block of code. When that happens, say with an “if-else” statement, the lines of code are indented to visually demonstrate where the code for the logic operation begins and ends. Keeping your code neatly indented allows any third-party developer or in-house agent to look at code quickly, find the function in error and resolve the problem.
Have A Conversation With The Future. Comment Accordingly.
Let’s say that one of the contact forms on your page is broken, or an image slider on one of your interior pages isn’t working correctly. Some feature of your website are not doing what they should, and it’s a problem. It would be pretty great if you could open the code and jump around to exactly where that feature was implemented by simply reading plain English. This is where obsessively meticulous comments become an absolute live saver. The chance to scroll past all of the computer-language and syntax for clear descriptions of how the code should operate works hand-in-hand with proper indentation. The developers you’ve brought on to correct the bug can get inside the mind of the original programmer, read how the code should work in theory, and cross reference it against the actual code itself to find out what went wrong. It’s all about needing to do less work to fix the issues faster.
Build Neapolitan Code Cuisine With Layer Separation
This idea works in tandem with the others above to make life simpler and more efficient. When building a website or application, your HTML, CSS, and most likely Javascript all perform separate functions. The HTML provides the skeletal architecture of the site keeping order and organizing the flow of content. The CSS handles the visual styling making sure that the backbone you provided with HTML looks exactly the way you need it to. And the Javascript handles many aspects of the user-experience, providing another level of functionality or design to what you’ve created.
Each of these are a layer, connected, but distinct in their purpose, and it is always best to keep these layers separated in their respective places. Imagine that your initial “cowboy” developer created a great little Javascript application on the fly, and implemented it on one of your pages. Then they decided to put the application on another four pages as well. Except, the application doesn’t work. Now you’ve got to fix the code in one location, then go back to the other four pages where the exact same error exists. Had the application been designated its own layer and kept in a tidy .js file and simply referenced by the pages in question, you could fix the code in one place and simply be done with it.
These three guides are pillars of proper code etiquette and they’re a great benchmark to measure the prospect of a new freelance or agency hire. If these rules are followed then you’ll save a bundle of money down the road on routine maintenance costs.
