H o w It Wo r k s P r ic i ng A bo ut U s ✈J P Si g n I n R e q ue s t Tri al

JULY 8, 2020 · AKIHIRO ASAHARA

15 Coding Best Practices to Follow

Coding best practices are vital for helping you and your team
create the best code possible. Here are 몭fteen of the best
practices to raise your code quality today. 

Today’s Agile world moves

fast. Customers are
demanding more features.
Stakeholders want it done
faster. And budgets seem to
always be shrinking. This can
add up to a lot of pressure P ho to by Th i s i sE ng i n ee r i ng RA E n g on
U ns p l as h
for the one’s who are
actually building the service or product. The ones who are
actually sitting at the keyboard and typing away. Those
people are the programmers and developers who every day
must 몭gure out how to construct the items required in a
faster, cheaper and more e몭cient way. 

With the pressure that’s seen in a lot of Agile projects, it can

be easy to get lax when it comes to writing code. Even the
best programmers may 몭nd themselves falling prey to
shortcuts when faced with looming deadlines. But in the end,
shortcuts when faced with looming deadlines. But in the end,
those practices only lead to poor quality, wasted e몭ort, and,
perhaps, worst of all, bad coding habits.

Instead of bad coding habits, set yourself up for success with

these coding best practices. Once you implement them,
they’ll save you and your team time, resources, and
headaches. Here are 몭fteen of the best coding practices that
you can start utilizing today for your team and yourself.  

1. ADHERE TO YOUR STYLE GUIDE

Whether it’s your organization’s own style guide or the
programming language’s style guide, one of the most
important coding best practices is to always follow your style
guide. Every programming language has one. This style guide
gives you all the details you need on how to indent code,
where to place braces and spaces, naming conventions, and
much more. 

Read the guide thoroughly and take the basics to heart. You
can always look up the less common requirements, but
remember to always apply the rules of the style guide. Never
cut corners when it comes to this area.

When you adhere to the rules of the style guide, other

programmers can more easily read your code and work on it,
if needed. If someone else is following the style guide, then
you can easily jump into that project. This is a coding best
practice because it allows for consistency throughout your
code. When you follow the rules of the style guide, you can
code. When you follow the rules of the style guide, you can
more easily 몭nd any mistakes or bugs. 

Many organizations will modify style guides to match their

own parameters. This can be a helpful way to make your
team even more e몭cient. If you plan to do this with your
team or company, make sure that your new guide is well
thought out and that everyone on the team is aware of the
customizations. Following the style guide’s rules is one of the
most vital and easy ways to implement coding best practices.

One tool that can help you and your team to stay on the
same page in terms of style is Sider. Sider is an automated
code review tool that analyzes your team’s pull requests on
the 몭y to help ensure that your codebase is consistent. It can
check for violations of style, as well as code quality, and it
helps your team stay up to speed on best practices, as well as
the rule-sets for each project.  

2. DON’T REINVENT THE WHEEL

It might seem counterintuitive that one of the coding best
practices is in regards to not coding something, but this is
another coding best practice that’s easy to take advantage of
and will help your project immensely. If something doesn’t
need to be coded, then don’t code it!

When considering the requirements for your project, ask

yourself questions about the features. Is this feature really
necessary? Who bene몭ts from this? Has someone else, either
in my organization or a third-party or even an open coding
in my organization or a third-party or even an open coding
repository, already coded a similar solution? When you think
about these questions, you may realize that you actually
don’t need any new code at all. You may 몭nd that the code
has already been written in-house. Or an a몭ordable SaaS tool
or open-source option could be available. 

It’s estimated that many software development projects

spend about forty to 몭fty percent of their time on rework that
could be avoided. Take the time to check and see if these
other options are available, and you’ll save time, e몭ort, and
dollars in the long run. All of that adds up. 

3. MAKE SURE YOUR CODE IS READABLE

Yes, we all want to be as e몭cient and optimized as possible.
And sometimes coders may want to show their skill and
talent by writing an entire method or function in one line.
After all, many of us became coders because we love to solve
complex coding challenges. But it doesn’t matter what
challenge you solved or how optimized your code is if no one
can read it. 

Instead of focusing on optimization, a coding best practice is

to focus on code that is readable. Readable code is
understandable code. Code that can be understood can be
integrated more easily, allowing for greater e몭ciency in the
project as a whole. As one of the coding best practices,
always focus on readable code. 

4. COMMENT AND DOCUMENT

When it comes to coding best practices, one habit that could
help you is to start each function or method you create with a
comment. In this comment, you can outline exactly what the
function or method does, what its parameters are, and what
it returns. You’ll also want to describe any possible errors or
exceptions. You can also summarize the major steps if your
code is particularly complex, as well as outline the role of
each 몭le and class and any contents in each class 몭eld. 

Doing this from the beginning keeps you consistent with

commenting. You may be tempted to come back and add this
in later, but the likelihood of you doing that is very low.
There’s a tendency to keep moving during your coding
sessions. 

In addition to any comments, be sure to document what it is

your code does, as a whole. This can be a short and sweet
README 몭le, but this guide should explain exactly the actions
that the code performs, including any dependencies, and it
should contain instructions on how to build, install, test, and
use your code. Comments and documentation help you to
ful몭ll another of the coding best practices. 

5. STAY DRY
When following the coding best practices, remember the DRY
Principle. DRY stands for Don’t Repeat Yourself, and the DRY
Principle states that “Every piece of knowledge must have a
single, unambiguous, authoritative representation within a
system.” This is also sometimes known as DIE: Duplication Is
Evil. 

Simply stated, the same piece of code should never be

repeated over and over. The purpose for most applications is
to automate repetitive tasks, so why spend time repeating
code? Never just copy-and-paste your code. Instead, you can
take out the most common parts of the code and abstract
them into a routine or class within certain parameters. 

Keep a de몭nitive version of your code in a single place, and

then let this version drive all other uses. You can do this by: 

• Creating an API reference guide from comments

• Automatically detecting unit tests through an annotation

or naming convention

• Generating both PDF and HTML documentation from a

single markup source

• Deriving object classes from a database schema  

When you follow the DRY principle, you are saving yourself
time and energy and following one of the most important
coding best practices. 

6. TEST YOUR CODE AND RESPOND TO

ERRORS
A vital coding best practice is to test your code. It doesn’t
matter how quickly you can write lines of code or how
optimized your code is if it doesn’t work. Routines can often
come back with error indications and raise exceptions. When
come back with error indications and raise exceptions. When
this happens, don’t just brush it o몭. Never assume that a disk
will not 몭ll up, or that your con몭guration 몭le will always be
there, or that a connection will never time out, or the host of
other reasons and excuses developers come up with to not
deal with exceptions. Instead, handle the error right away.
Yes, this can make your code longer and possibly even
subtract from its readability, but when you ignore the
problem, it doesn’t go away. Some end-user will 몭nd it
someday, and that will come back on you, your team, and
possibly your whole organization. You don’t want code going
out into the world with any sort of error that you knew you
could 몭x. 

Along those lines, automated testing tools today have

progressed far beyond where they were previously. These
automated testing tools help to validate builds and releases
and also make your code more supportable. Tests are a form
of documentation. They tell you how the code is supposed to
act. Continuous testing helps to provide meaningful feedback
to developers. From there, programmers and developers can
quickly address the issues and make any necessary changes.
Don’t try to sweep any coding problems under the rug. Test
your code often and make the changes required, so that you
follow coding best practices. 

7. LIMIT YOUR LINE LENGTH

Have you ever read a newspaper article? Or a blog article?
Our eyes like tall, narrow blocks of text. Long lines are hard
to read. 

Because of this, one of the easier coding best practices to

utilize is limiting your line length to a certain number of
characters. If you are reading code from a terminal window, a
good length is about eighty characters. 

In addition to keeping your lines short, you should also split

your code as a whole into short and focused units. Again,
every function, method, or block of code should be split into
a section that will easily 몭t into a decent-sized window. This
usually means about twenty-몭ve to 몭fty lines of code. If you
몭nd your code is longer than 몭fty lines, split it up into
shorter, more digestible sections. When you divide these long
sections of code into blocks, consider adding a comment at
the beginning of each block, describing the function or the
block of code. 

If the code is a simple repetitive sequence, you may 몭nd that

it can extend into a longer block, but even then, consider
driving it through a data table. Also, search for a way to keep
your code short and sweet. This is another of the most
important of coding best practices. 

8. CONSISTENCY IS KEY
When looking at coding best practices, consistency is always
important. It’s important to do things that are similar in ways
that are similar. When you’re developing a new routine with a
functionality that closely matches an existing routine, use a
comparable name, parameter order, and structure for the
comparable name, parameter order, and structure for the
code body. The same goes for classes. Make the new class
adhere to the same interface and match any new names with
those already existing. 

Another way to keep your code consistent is to follow the

conventions of your coding framework. For example, it’s
often common practice to represent ranges half-open, with
inclusive on the left and exclusive on the right. If you 몭nd
that there is no convention for something you are working
on, create one amongst your team and stick to it. This will
make your code more readable and help you to 몭nd any bugs
or errors. Staying consistent is essential when it comes to
coding best practices. 

9. AVOID HARD-CODING
As much as possible, avoid hard-coding anything, other than
constants. System-level settings, usernames, passwords, and
other con몭guration information should never be hard-coded.
Some developers may try to take shortcuts when developing
prototypes, and then these prototypes can 몭nd their way into
production environments. This is the opposite of best coding
practices. Hard coding in these cases is not technical debt,
but could be seen as irresponsible with major consequences.
Should that code ever become accessible, it represents a
huge security risk when endpoints and access credentials are
exposed. 

Security pitfalls should always be avoided, and they don’t

always come from the internet. Depending on your
always come from the internet. Depending on your
programming language, you may have to watch out for bu몭er
over몭ows, cross-site scripting, and similar problems. Learn
about the possible risks inherent in your language and in
hard-coding, and avoid them as much as possible. Safety is
not only a coding best practice but a best practice for every
step of the project. 

10. AVOID CODING WHEN TIRED

In today’s Agile world, coding may seem like a never-ending
task. And some coders and developers believe in burning the
midnight oil with coding marathons. But working more
doesn’t necessarily lead to better code. Certain studies have
shown that individuals are two to 몭ve times more likely to
make a mistake when they are tired than when they are alert
and full of energy. When you are tired or distracted, you’ll
inevitably make mistakes which either you’ll have to 몭x later,
making that time you spent essentially wasted, or you won’t
catch the mistake at all, meaning that the mistake will be
found later in QA or maybe not until the end-user gets the
product in their hand. 

Many businesses today are realizing the advantage of shorter

coding sessions and, some, even shorter workdays. As a
software developer or coder, take breaks during the day
when you are tired. Go for a walk. Get a cup of co몭ee. Have a
conversation with a friend. Do something to help your mind
refresh and regroup. Banging away at the keyboard when
you’re exhausted or in a bad mood doesn’t help anyone.
Sure, sometimes deadlines
come up and you may 몭nd
yourself in an extra-long
session, but this should not
become a regular
occurrence. If this does
happen regularly, take a look
at your team and your day- P ho to b y C hris ti an Erf urt o n U ns p l a sh

T r yi n g to cod e wh e n yo u ’r e t ir ed o nl y l e a d s
to-day practices. Are you t o mo r e mi s ta k e s. A v oi d i t.

being distracted by other

non-programming activities? Is your team functioning as a
unit? Marathon coding sessions are often symptoms of bigger
problems in the team. Do your best to avoid coding when
tired, and you’ll be following another of the coding best
practices. 

11. KEEP IT SIMPLE

Just as one of the coding best practices is to keep your code
readable, you should also strive to keep it simple. Complex
code means the likelihood of more bugs and more mistakes.
Try to make your code only do what it needs to do and
nothing more. Keep your design focused on the project’s
current needs. 

Try to avoid complex coding heroics. Don’t make

parameterized classes, factory methods, or use out-of-date
interfaces that few coders are familiar with, especially if you
are using these methods to 몭x problems that don’t yet exist.
Including some code to avoid a potential problem down the
road sounds like a good idea on paper, but it can often
muddle your code and leave future coders confused as to
what it is or why it’s there. Should a problem arise in the
future, you will have the opportunity to incorporate a new
solution. Until then, keep it simple. That’s another best
practice. 

12. USE DESCRIPTIVE NAMES

In the past, programmers faced a lot of restrictions when it
came to naming conventions. They were often limited by
slow, clunky interfaces and needed to save time, ink, and
paper. So they would inevitably contract their variable
names. Today, we face few of those same restrictions. And
yet the culture of vague naming conventions continues. A
coding best practice that will save you headaches down the
line is to be descriptive in your naming conventions. 

In the modern programming community, you’re free to use

long and descriptive names to help yourself and your
colleagues understand exactly what your code does. Sure,
you can give it a shorter name now, but will you remember
what exactly that name meant a month from now? Will the
next coder who comes on to the project be able to
understand exactly what that name was for? 

Make your names as speci몭c as possible. For example instead

of simply writing “getLowest”, you might write
“getLowestPrice”. Or did you actually mean “getBestPrice”?
Think about what you’re actually trying to accomplish with
your code and name it appropriately. 

Additionally, when following coding best practices, there are

some simple naming conventions. Class and type names are
nouns. Names for methods should contain a verb. If a
method returns a value indicating whether something is true
or not, then start the method name with “is”. Does the
method return an object’s property? Start the name with
“get”. Does it set a property? Start with “set”. 

13. YOUR CODE SHOULD BE PORTABLE

AND BUILDABLE
Unless there is a very good reason, your code should always
be able to function across platforms and frameworks. Store
the program’s messages away from the code. Never hard-
code certain cultural conventions, like the format for dates.
These conventions must be adaptable to countries outside of
your home country.  

Additionally, your code must be buildable. It’s no good if it

can’t be distributed. Use an automation tool that allows you
to build your code into a form that’s ready for distribution
and that can be tested quickly. Consider setting up a
continuous integration system to check, build, and test your
code for every change that is made. When following coding
best practices, always make your code portable and
buildable.  

14. VERSION CONTROL IS YOUR FRIEND

14. VERSION CONTROL IS YOUR FRIEND
Everything in your system, from your code and
documentation to tool sources, build scripts, and test data,
should be stored under version control. Version control is
important for several reasons. It helps with collaboration.
With version control, developers can work concurrently on
the same set of 몭les. It also allows you to restore previous
versions of your code if something becomes messed up or
broken. Version control also allows you to track the history of
changes in the code. You can easily track why certain changes
were made to the code in the past. It also acts as a backup
for your code. 

Today, tools like Git and GitHub -as well as a host of other
similar repositories- make it cheap and easy to take
advantage of everything that version control has to o몭er. If
you’re not already using one of these tools, do your research
and see which one best 몭ts your needs. 

And, of course, always save your work often. You never know
when a dead battery, software glitch, power outage, or worse
will happen. Anything can result in a loss of data, causing you
a lot of unnecessary stress and double work. Save your work
regularly and back it up to the version control system that
you choose. It’s a simple coding best practice to follow. 

15.  COLLABORATE
As a programmer, you spend a lot of time sitting at your
desk, typing away. It can be easy to think that you’re working
desk, typing away. It can be easy to think that you’re working
on something alone, but you’re not. You’re part of a team,
and you all share a common goal - ideally, to create the
highest possible product in the fastest amount of time. So, in
this way, it’s not bene몭cial for you to work alone. 

Instead, strive to work together with your teammates. Share

your progress and ideas with them. Communicate regularly
and consistently, whether it’s during the weekly standup or
just around the co몭ee machine. This not only helps you, but
it also helps your team as a whole. 

Collaboration leads to regular new and better ideas. When

you speak to your teammates, you may 몭nd that they have a
better way of approaching a problem that you had not
thought of. Or you may 몭nd that they approach coding in a
completely di몭erent way. In working with other team
members, often you’ll 몭nd a new and unique third approach
(as a combination of your two previous approaches) that
leads to a new and more e몭cient way of doing things for your
team. 

If you’re a more experienced programmer, you may have the

opportunity to mentor a junior programmer. If you’re fresh
out of school, you might 몭nd a mentor who can teach you
something that they’ve learned through their years of work.
Plus, when you talk to your team, you just might 몭nd that you
become friends, which can lead to a whole new world of
experiences. Collaboration is one of the most overlooked
coding best practices, but it’s an essential one, not only for
your project, but for your work satisfaction.
your project, but for your work satisfaction.

A BONUS CODING BEST PRACTICE? HAVE

FUN
At the end of the day, it’s important to remember why you
got into coding in the 몭rst place: hopefully, because you
enjoy it on some level. As a programmer, you spend a large
number of hours writing code, so try to have fun. Try to work
on projects that are interesting to you. Or 몭nd a piece of the
project that you enjoy and focus on that. Work in an industry
that you like, and be around people that you like to be
around. Remember that you’re not working in a vacuum.
You’re part of a team, and when you work together, everyone
bene몭ts. 

Coding best practices are about writing readable code, being

consistent, and saving everything to version control. But
they’re also about collaboration and enjoying the process of
what you’re doing. When you do that, you may 몭nd that you
are writing better code than ever before.  

5 Technical Team Management Using Scrum Story Points in

Tips Scrum Teams
 Copyright 2020 Sider Corporation

FAQ Help Get Involved Security Privacy Terms Contact Blog