Reading a bad code is like speaking a language you don’t know — make you feel awkwardly!
Nowadays, there is a huge problem with reading a code written other developers. Usually, it is much easier to write a new code by your own, than trying to read and understand others’ one. However, if everyone would follow the rules of good manners, when he is writing a code, it might be easier to live.
The code design standard is usually accepted and used by group of software developers to uniformly format shared code. The goal of adopting and using the standard is to simplify the perception of the program code by the person, to minimize the load on memory and vision while reading the program.
So, let’s consider the main rules of writing and few advices helping to raise your level in the eyes of other programmers.
Rule 1 “Comments”:
Comment as much as you can. It will help people to understand what’s going on at some piece of code.
A good developer should comment:
- every routine or function (what will do this method, what you will get in the end);
- all variables (just names you gives to variables don’t let to know where and why it will be used);
- classes and files (write about role and content before the class’ code).
It is very boring and monotonous work, but it is necessary.
Write comments while writing a code!
If you want to do it after finishing the task — stop lying to yourself!
Rule 2 “Names”:
Use descriptive names! It’s very important for both you and other developers. It helps to understand what is the appointment of variable, or class, or anything else.
How good developers should choose the correct name:
- long names for classes, methods, variables
(like ‘readingFromFile’ or ‘countingCars’ for functions, like ‘temperature’ or ‘numberOfVisitors’ for variables);
- short names for indexes, keys
(if you need to organize cycle choose one letter, for example: ‘(for i:=1, i++)’);
- the name matches with functionality
(if this function gets something, name it ‘getSome’).
Don’t forget that all names must be unique, otherwise, it’s easy to get confused.
Rule 3 “Style”:
Every programming language has a styleguide that tells you in great detail how to indent your code, where to put spaces and braces, how to name stuff, how to comment — all the good and bad practices.
Follow this guide and you’ll escape mistakes.
Good manners are to include:
- indents (helps to find finish or start of each function);
- gaps (helps to identify operators);
- camel style (new word — big letter, it will look like ‘pieceOfMyCode’).
Rule 4 “Simplicity”:
Try to write as simple as it possible. Don’t write everything in the main part. Create functions, classes e.t.c.
Otherwise, it would be impossible to find an error or to understand what’s going on in this program.
Advices from the professionals:
- No copy past! (make methods for it)
- All code must be on the screen!
- Check errors!
- Write code, when you are in a good mood.
All of these four simple rules and four advices will help you to find a nice programmer.
How to understand what kind of person you need?
Hiring a developer for a project you should be sure that he will easily get on with other programmers, designers and other employees despite being talented and professional.
Ask him or her to write a simple code without mentioning that comments are neccessary. The one who will add some correct comments is the person you’re looking for!