"Good programmers spend a lot of time dealing with other programmers' broken code anyway." From http://programmers.stackexchange.com/questions/181817/should-your-best-programmers-have-to-check-everyone-elses-code-into-source-cont
If you work on another person's code, try to find the assertions. These usually lead the way to understanding and debugging the code. Rewrite bad code, and write and test code in small pieces.
Begin finding bugs by reproducing the problem. Start by getting exact input if you can. Try reproducing the problem in your test environment with as little data as possible. Ask about all the conditions present when the problem occurred (for example, other users, batch jobs, etc.)
Errors are most frequent on boundary conditions. For example, beginning of file, end of file, empty file, full file, beginning of loop, end of loop, entry to module, exit from module, value less than limit (instead of less than or equal), table overflow, or table empty. When verifying code, check that the boundary conditions are what you expect.
Here are some suggestions from Elements of Programming Style:
If you work on another person's code, try to find the assertions. These usually lead the way to understanding and debugging the code. Rewrite bad code, and write and test code in small pieces.
Begin finding bugs by reproducing the problem. Start by getting exact input if you can. Try reproducing the problem in your test environment with as little data as possible. Ask about all the conditions present when the problem occurred (for example, other users, batch jobs, etc.)
Errors are most frequent on boundary conditions. For example, beginning of file, end of file, empty file, full file, beginning of loop, end of loop, entry to module, exit from module, value less than limit (instead of less than or equal), table overflow, or table empty. When verifying code, check that the boundary conditions are what you expect.
Here are some suggestions from Elements of Programming Style:
- Make sure all variables are initialized before use.
- Don't stop at one bug (there are always more).
- Initialize constants in the DATA DIVISION; initialize variables with executable code.
- Watch for off-by-one errors.
- Test programs at their boundary values.
- Program defensively.