0% found this document useful (0 votes)
31 views7 pages

11 Tips That Will Help You Write Better Code

The document provides 11 tips for writing better code: 1) use consistent indentation, 2) add comments to explain complicated code, and 3) use a consistent naming scheme. It emphasizes making code readable, maintainable, and organized by breaking large tasks into smaller chunks, avoiding long lines, and refactoring code over time. Design patterns and deleting unnecessary code are also recommended. The overall goal is writing code that is easy for others to understand and maintain.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views7 pages

11 Tips That Will Help You Write Better Code

The document provides 11 tips for writing better code: 1) use consistent indentation, 2) add comments to explain complicated code, and 3) use a consistent naming scheme. It emphasizes making code readable, maintainable, and organized by breaking large tasks into smaller chunks, avoiding long lines, and refactoring code over time. Design patterns and deleting unnecessary code are also recommended. The overall goal is writing code that is easy for others to understand and maintain.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

11 Tips That Will Help You Write Better Code

1) Decide on the indentation and keep it that way


Style is important, not to make code look pretty, but because it
helps with reading, editing, and understanding. The code
should be divided into logical units and it’s important to keep
the style consistent throughout the whole document. In most
of the programming languages, spaces and indentations do not
affect the function. If you are using an IDE, it is recommended
that you create a formatted config so everyone uses the same
one.
Every developer will be more comfortable with one style or
another. If you start working on code that was written by
someone else, the style should be followed.
There are different kinds of indentation that can be used:
1. if
(hours < 24 && minutes < 60 && seconds < 60) {
2. return
true;
3. } else
{
4. return
false;
5. }
6. if
(hours < 24 && minutes < 60 && seconds < 60)
7. {
8. return
true;
9. }
10. else

11. {
12. return
false;
13. }
14. if
( hours < 24

15. && minutes < 60


16. && seconds < 60
17. )
18. {return
true
19. ;} else

20. {return
false
21. ;}
There is no right or wrong, but just the way you feel most
comfortable with.

2) Make comments
There is a love and hate relationship with comments and there
is a fine line between helpful comments and redundant ones.
It is, in fact, very useful to use them to explain the code,
especially complicated passages. Comments will help you and
others understand why you did what you did. It may seem
obvious to you when you are writing it, but will others who

work on the code understand it? Will you remember what you
did after a month or a year?
Comments are worthwhile as long as they are a few and written
for key passages. Too many comments at every single line will
make the code completely unreadable and messy, no matter
how neat the style and consistent the indentation.
3) Consistent name scheme
Usually, Languages have their own naming conventions. For
example, java uses camelCase. Naming needs to stay
consistent, otherwise, it will very difficult to find things inside
the document.
There are two main ways to name things:
o camelCase: which means that every word of the file
name is capitalized except for the first one, e.g.
nameFilesConsistently
o Underscores: in this case you write underscores
between each word, e.g. name_files_consistently

4) Don’t repeat code


Repeating code will make your document very long and it will
break the reading flow. If you have pieces of code that will be
used more then ones, it is preferable to make a separate file
and include the file path when needed.

A typical example is a web page: most pages will have the same
header and footer, but there is no need to copy-paste the same
code onto every page, just link to it.

5) Avoid writing long code lines


Writing long lines of code makes it very difficult to read, moving
back and forth horizontally, losing any sense of what it’s
actually written. Style and indentation will help with this.
Keep also in mind, that the terminal window limits characters
to 80 per line, so if the code is longer, it will be just cut, making
it incomprehensible.

6) Break down a big task into smaller chunks


A whole new feature will never be just a few lines long. Even
with comments, a 500-lines function will still be a pain to
browse, understand and edit.
Your best choice is to break down the big task into a smaller
chunk of code.

7) Organize your program into smaller files


Having a file with thousands of lines of code doesn’t help
anyone, but broken down into shorter files organized based on
function or feature will help you get right to the point when
something needs fixing. Having the whole code organized in
files and folders is very good for maintainability, especially if
different teams and people are working on it.

8) Write clever code that is also readable


Write clever code, but the main focus should be on readability
and maintainability.
If the code is kept short it is easier to go through, but if it’s too
smart, it will take too much time to understand and edit it. You
know that your code was too clever if you can’t read it after 3
months. So be clever but not too much!

9) Code refactoring
Every developer knows this – you write some code because you
want to finish the feature and in the end, it works. When you
then look at it after some time you think – did I really write
that? I could have shortened it so much! So you start rewriting
that piece of code better, probably shorter, without changing
any functionality.

10) Delete unnecessary code


You wrote new code, great. Is the new code working? If yes,
then just delete the old one!
There is no point in keeping the old code, and comment it out.
It will just look messy and unnecessarily long.

11) Use Design Patterns


A design pattern is a general reusable solution to a commonly
occurring problem within a given context in software design.

Best practices to write better code – conclusion


Writing and reading code may look “easy” if you know what
you are doing, but you are probably not the only one working
on the code. If you work in a team, it is a good idea to define
best practices, guidelines, so that it is easier for the other team
members to read, edit, review and maintain the code.
Following best practices will also help you be a better
programmer overall. The main keywords to always keep in
mind are consistency, simplicity, and readability.

Recommended reads:
 Design Patterns: Elements of Reusable Object-Oriented
Software
 Clean Code
 Head First Design Patterns: A Brain-Friendly Guide

You might also like