|
|
Ultimate Developer Tips and Tricks
Posted On April 9, 2007 by Geeta Priya filed under Miscellaneous
Though these tips and tricks are supposed to be meant for any developer, there is some partiality towards C, C++ and Java since most of the authors involved in compiling them like these languages over others. Moreover, one out of two developers are familiar with these languages.
Now there are two kinds of developers. One, the professional and other the amateur. Let us start with a tip for the amateur, which is applicable even to a pro at some time or other.
1. Code at your pace—
Development is a bit of an art, more than science. And researchers say that more creative and better code is written when developers work at their own pace. This cannot be the case with a developer who is working on projects which needs to be closed within a specific time period. But even in that case, trying to work faster can result in more buggier code, and more time spent during debugging.
2. Never lose your patience while programming—
Trying to remove a bug for past two hours, and you are going mad. Go for a walk, return to the table and then start working. It will even be better if you can leave that piece of code and start working on another. Come back and tomorrow and give it a short. Don't keep banging at the same subject until it works perfectly. Your brain will get saturated and progress will get slower. By turning to another subject or goal for a moment, or just doing something completely different, your right side of the brain will have time to work on the subjects that are seemingly at rest. Don't depend too much on your left brain for too long, especially when things get tough.
3. Test to prove that it does not work -
The first Golden rule of Testing says that when you test a program, you test to prove that it does not work. If you try proving that it works, then you are likely to miss out on a few loopholes present in the code.
4. Get a second opinion-
The second Golden rule of Testing asks you to test the code from every conceivable angle, and must be certified bug free by another programmer. However good programmer you are, you should not celebrate the fact that your code is bug-free, till another programmer tests it. Preferably the second programmer should not have any clue about the logic you have used for coding, but only have an idea about problem you are solving.
5. Think long term-
Think OOPS. Object Oriented programming is not just about programming or coding, and can be implemented in the very way you think and plan a project. For example, when you start a new project, think of components you can use from other projects. Likewise, think of components you can make and use later on in other projects. Modularity and robustness will cut down future development time substantially.
6. Do not get stuck at an error line-
An error in line number 121 does not necessarily mean that a bug exists there. If you are coding using any compiler languages such as C, remember that error can occur because of problems with code in other lines too. Hence, never spend too much time fixing a code at a particular line.
7. Write the comments clearly-
Comments made in a code are not just meant for yourself. Many developers make the elementary mistake of writing comments, which is decipherable only for themselves. Some times a month or two down the line even they cannot understand it. You make comments so that every one can read it and understand it.
8. Have the complete plan ready before the start-
Design first, program later. Only start programming when you have a clear picture in your head of what you want to achieve. This helps programming productivity very much. Nowadays, there are several tools that help you design. If you do not have those tools, start with a pen and paper before you write.
9. Divide goals into subgoals-
Create goals and subgoals to keep going ahead. You'll need subgoals if a project seems large. Design the global scheme of things first, than create subgoals that can be achieved without the rest of the application working yet. We always like to see results early on, so we go for things that we can check. It happens to all of us, not just programmers. Filling in subgoals gives you the feeling that you're actually getting forward, an important thing.
10. Prepare a pseudo-code before actual coding-
Write psuedo-code, if not on paper in your mind. Remember the good old days when DOS ruled the world. We all used to write psuedo-code before actual coding starts. You used to write psuedo-code to get ideas across to another programmer. Before you write a function or a class it is worthwhile writing the program in a few line of psuedo-code before you actually write in your IDE. Also remember that your psuedo-code can have bugs and syntax errors, and no paper is going to complain.
11. Compile the psuedo-code yourself—
Writing psuedo-code should not be a blind exercise by itself. Compile the code, mentally check out how values are passed or changed, then start writing the code.
12. Use Indentation wherever possible –
Sometimes indentation can be a pain. Some of the Python developers we know curse the indentation in the language IDEs. But remember that developers of the wonderful language kept indentation so that another developers understands the code better, and nesting and loops are visible.
13. Keep your functions short-
Don't try to build the whole program with one function. It will be much easier for you to write working code if your functions do only one basic thing. I have written many functions, which are only a few lines long. That makes them easier to test and easier to debug.
14. Write each function separately-
Write each function separately, and test it thoroughly before using it. If you write all your code beforehand and test it all at once, it will be much harder for you to debug it.
15. Be a master in debugging-
The single-most important aspect of programming is debugging. If you cannot debug your own code, you will never be able to program successfully. You will spend most of your time working in one of the labs without the assistance of the instructor. If every time you run into difficulty you simply ask for help, you will not learn how to write and debug good code.
16. Keep track of error locations-
The most important aspect of debugging is to identify the exact location of the error. The simplest way to do that is to print messages to the screen. You should print notes saying where you are in the code, and also print the value of all the variables you have read from the user or from a file. You should also print the values of all variables, which you have performed calculations on.
17. Make a thorough test-
Use test cases that use all the loops, control structures, and functions in the program while testing. A hidden bug during the last days can be like a time bomb.
18. Think laterally to locate errors-
If you cannot unveil a logical error, try analyzing the logic from another angle. Preferably try reversing the logic and then start analyzing it. You may have a solution.
19. An action is either a repeat-until loop or while-do loop-
In almost all programming languages, rules surrounding control structures are the same. Here is the first golden rule. Should the action be performed at least once? If so, it is a repeat-until loop, otherwise, it is a while-do loop.
20. The questions to be asked-
When a control structure is used, ask these questions
a) Under what condition should the action be repeated?
b) Is there an operation to be done before the loop? Do you need to initialize any variables used in the loop?
c) Is there an operation to be done for each iteration? Do you need to advance to the next number or the next item for each iteration?
d) How are the variables involved in the condition of the loop affected by each iteration?
e) Are you sure that the loop will eventually exit? Why will it eventually exit?
f) What is the condition that the actions depend on?
g) If an action needs to be performed not repeatedly and not conditionally, it is an assignment.
h) Under what condition should the program stop repeating the action and move on?
i) Exactly what should be done if the condition is true (or false)? In this case the "then" part should be used.
Now, let us look at C and C++ specific tips:
1. Never use 'delete' directly in C++- You should never use `delete’ directly in C++ because it has a fatal design flaw; and every such statement leaves by definition a dangling pointer. And remember, dangling pointers (pointers which points to unallocated storage, which is mostly intact but can be overwritten at the next allocation) are a big contributor to those 'mysterious' bugs that happen now and then.
2. Never use 'free' directly- For the same reasons as with 'delete', this creates dangling pointers by definition (something to which languages like Pascal and Basic are much less prone).
3. Keep your functions short- Keeping the functions short will allow you to keep the bird's eye view of your project better. And a better view means a clearer picture means less bugs, and more flexibility. This rule is true for just any language not just C or C++.
4. Keep variable names and function names descriptive- Always keep the variable names and function names descriptive. This will help if your project takes more than a month. You can easily understand that a function name fun_delete_old_records, stands for a function to delete old records. But in case you named it as fdolor, we doubt anyone would have understood what it stands for after sometime.
Now there are two kinds of developers. One, the professional and other the amateur. Let us start with a tip for the amateur, which is applicable even to a pro at some time or other.
1. Code at your pace—
Development is a bit of an art, more than science. And researchers say that more creative and better code is written when developers work at their own pace. This cannot be the case with a developer who is working on projects which needs to be closed within a specific time period. But even in that case, trying to work faster can result in more buggier code, and more time spent during debugging.
2. Never lose your patience while programming—
Trying to remove a bug for past two hours, and you are going mad. Go for a walk, return to the table and then start working. It will even be better if you can leave that piece of code and start working on another. Come back and tomorrow and give it a short. Don't keep banging at the same subject until it works perfectly. Your brain will get saturated and progress will get slower. By turning to another subject or goal for a moment, or just doing something completely different, your right side of the brain will have time to work on the subjects that are seemingly at rest. Don't depend too much on your left brain for too long, especially when things get tough.
3. Test to prove that it does not work -
The first Golden rule of Testing says that when you test a program, you test to prove that it does not work. If you try proving that it works, then you are likely to miss out on a few loopholes present in the code.
4. Get a second opinion-
The second Golden rule of Testing asks you to test the code from every conceivable angle, and must be certified bug free by another programmer. However good programmer you are, you should not celebrate the fact that your code is bug-free, till another programmer tests it. Preferably the second programmer should not have any clue about the logic you have used for coding, but only have an idea about problem you are solving.
5. Think long term-
Think OOPS. Object Oriented programming is not just about programming or coding, and can be implemented in the very way you think and plan a project. For example, when you start a new project, think of components you can use from other projects. Likewise, think of components you can make and use later on in other projects. Modularity and robustness will cut down future development time substantially.
6. Do not get stuck at an error line-
An error in line number 121 does not necessarily mean that a bug exists there. If you are coding using any compiler languages such as C, remember that error can occur because of problems with code in other lines too. Hence, never spend too much time fixing a code at a particular line.
7. Write the comments clearly-
Comments made in a code are not just meant for yourself. Many developers make the elementary mistake of writing comments, which is decipherable only for themselves. Some times a month or two down the line even they cannot understand it. You make comments so that every one can read it and understand it.
8. Have the complete plan ready before the start-
Design first, program later. Only start programming when you have a clear picture in your head of what you want to achieve. This helps programming productivity very much. Nowadays, there are several tools that help you design. If you do not have those tools, start with a pen and paper before you write.
9. Divide goals into subgoals-
Create goals and subgoals to keep going ahead. You'll need subgoals if a project seems large. Design the global scheme of things first, than create subgoals that can be achieved without the rest of the application working yet. We always like to see results early on, so we go for things that we can check. It happens to all of us, not just programmers. Filling in subgoals gives you the feeling that you're actually getting forward, an important thing.
10. Prepare a pseudo-code before actual coding-
Write psuedo-code, if not on paper in your mind. Remember the good old days when DOS ruled the world. We all used to write psuedo-code before actual coding starts. You used to write psuedo-code to get ideas across to another programmer. Before you write a function or a class it is worthwhile writing the program in a few line of psuedo-code before you actually write in your IDE. Also remember that your psuedo-code can have bugs and syntax errors, and no paper is going to complain.
11. Compile the psuedo-code yourself—
Writing psuedo-code should not be a blind exercise by itself. Compile the code, mentally check out how values are passed or changed, then start writing the code.
12. Use Indentation wherever possible –
Sometimes indentation can be a pain. Some of the Python developers we know curse the indentation in the language IDEs. But remember that developers of the wonderful language kept indentation so that another developers understands the code better, and nesting and loops are visible.
13. Keep your functions short-
Don't try to build the whole program with one function. It will be much easier for you to write working code if your functions do only one basic thing. I have written many functions, which are only a few lines long. That makes them easier to test and easier to debug.
14. Write each function separately-
Write each function separately, and test it thoroughly before using it. If you write all your code beforehand and test it all at once, it will be much harder for you to debug it.
15. Be a master in debugging-
The single-most important aspect of programming is debugging. If you cannot debug your own code, you will never be able to program successfully. You will spend most of your time working in one of the labs without the assistance of the instructor. If every time you run into difficulty you simply ask for help, you will not learn how to write and debug good code.
16. Keep track of error locations-
The most important aspect of debugging is to identify the exact location of the error. The simplest way to do that is to print messages to the screen. You should print notes saying where you are in the code, and also print the value of all the variables you have read from the user or from a file. You should also print the values of all variables, which you have performed calculations on.
17. Make a thorough test-
Use test cases that use all the loops, control structures, and functions in the program while testing. A hidden bug during the last days can be like a time bomb.
18. Think laterally to locate errors-
If you cannot unveil a logical error, try analyzing the logic from another angle. Preferably try reversing the logic and then start analyzing it. You may have a solution.
19. An action is either a repeat-until loop or while-do loop-
In almost all programming languages, rules surrounding control structures are the same. Here is the first golden rule. Should the action be performed at least once? If so, it is a repeat-until loop, otherwise, it is a while-do loop.
20. The questions to be asked-
When a control structure is used, ask these questions
a) Under what condition should the action be repeated?
b) Is there an operation to be done before the loop? Do you need to initialize any variables used in the loop?
c) Is there an operation to be done for each iteration? Do you need to advance to the next number or the next item for each iteration?
d) How are the variables involved in the condition of the loop affected by each iteration?
e) Are you sure that the loop will eventually exit? Why will it eventually exit?
f) What is the condition that the actions depend on?
g) If an action needs to be performed not repeatedly and not conditionally, it is an assignment.
h) Under what condition should the program stop repeating the action and move on?
i) Exactly what should be done if the condition is true (or false)? In this case the "then" part should be used.
Now, let us look at C and C++ specific tips:
1. Never use 'delete' directly in C++- You should never use `delete’ directly in C++ because it has a fatal design flaw; and every such statement leaves by definition a dangling pointer. And remember, dangling pointers (pointers which points to unallocated storage, which is mostly intact but can be overwritten at the next allocation) are a big contributor to those 'mysterious' bugs that happen now and then.
2. Never use 'free' directly- For the same reasons as with 'delete', this creates dangling pointers by definition (something to which languages like Pascal and Basic are much less prone).
3. Keep your functions short- Keeping the functions short will allow you to keep the bird's eye view of your project better. And a better view means a clearer picture means less bugs, and more flexibility. This rule is true for just any language not just C or C++.
4. Keep variable names and function names descriptive- Always keep the variable names and function names descriptive. This will help if your project takes more than a month. You can easily understand that a function name fun_delete_old_records, stands for a function to delete old records. But in case you named it as fdolor, we doubt anyone would have understood what it stands for after sometime.