]
]Whether you like coding or hate it, these tips will help you in successfully completing the implementation tasks assigned to you.
Good code is its own best
documentation. As you’re about to add a comment, ask yourself, ‘How can I
improve the code so that this comment isn’t needed?’ Improve the code and then
document it to make it even clearer.
--Steve McConnell
[ source]
Often simple code runs faster. Do not complicate code for the sake of performance, unless you have proof that a more complex code has a sufficient performance edge. As the old adage goes, KISS (keep it simple, stupid - don't try to write clever code)
An application should be sufficiently verbose/interactive to avoid the doubt "is the application stuck or simply busy processing some data?" For example, if your application does an internal calculation that could take more than a couple of seconds, produce some output at short intervals during such a long process(e.g., show the number of records processed at each stage) - this shows that the application is simply busy, and had not crashed.
A prototype is not a production quality system. It is a quick and dirty system you slapped together to verify certain things (e.g., to verify the architectural integrity). It is meant to be thrown away, and you are meant to keep only the knowledge you gained from it. Having said that, most of you will find it hard to throw the prototype away, after spending so much time on it (because of your inexperience, you probably spent more time on the prototype than it really required). If you really insist on building the real system on top of the prototype, devote the next iteration to converting the prototype to a production quality system. This will require adding unit tests, error handling code, documentation, remove hard coding, logging code, refactoring, etc.
Some bugs crops up only occasionally, and they are hard to reproduce under test conditions. If such a bug crashed your system, there should be an easy way to figure out what went wrong. If your application writes internal state information to a log file at different points of operation, you can simply look at that log file for clues.
Printing a greeting message at startup (or a splash screen, if your application has a UI) - showing some useful data like the version number - not only makes your application look more professional, but also can help you catch problems of "releasing an outdated version"
Using global variables creates implicit links between code that uses the global variable. Avoid them as much as possible.
The pragmatic programmer calls this the DRY (Don't Repeat Yourself) principle. Code duplication (especially, when you copy-paste-modify code) often indicates a poor quality implementation. While it is not possible to have zero duplication, always think twice before duplicating code; most often there is a better alternative.
Most students invent their own set of terminology to refer to things in the problem domain. This terminology eventually makes it to the program, as class/function/variable names. Instead, stick to the terms used in the problem domain. For example, if the specification calls a component of the system "the projector", do not refer to the same component as "the visualizer" in your code. While the latter may be a better match for what that component actually does, it could cause unnecessary confusion (and much annoyance) for the evaluator/supervisor/customer.
Being new at programming, no one expects you to write quality code in one shot. However, if you decided to live with messy code you produced, it will get messier as time goes on (have you heard about the "broken windows theory"?). The remedy is refactoring. Refactor often to improve your code structure.
Appoint someone to oversee the code quality (i.e., a code quality guru). He/she can choose a coding standard to adopt (for most languages, there are several coding standards floating around). Prune it if it is too lengthy - circulating a 50 page coding standard will not help.
A coding standard does not specify everything. You will have to come up with some more conventions for your team e.g. naming conventions, where to store source code of different members, how to do integration testing etc. But remember, conventions only work only if the whole team follows them.
You code a little, try it, and it seems to work. You code some more, try it, and it still seems to work. After many rounds of coding like this, the program suddenly stops working, and after hours of trying to fix it, you still cannot figure out why. That's programming by coincidence. You code worked up to now, by coincidence, not because it was 100% correct.
Instead, code a little, test it thoroughly, before coding some more. See here for more advice on testing.
Hold at least one code-review session at an early stage of the project. Use this session to go over each others code. Discuss different styles each one has adopted, and choose one for the whole team to follow. Warning: Things can turn ugly in this discussion!
There is no such this as "perfect" code. While you should not release sloppy software, do not hold up progress by insisting on a yet another minor improvement to an already "good enough" code.
To quote from The pragmatic programmer: We want to see pride of ownership. "I wrote this, and I stand behind my work."
By making you put your name against the code your wrote (e.g., as a comment at the beginning of the code), we encourage you to write code that you are proud to call your work. This is also useful during grading the quality of work by individual team members.
To most of us, coding is fun. If it is not fun for you, you are probably not doing it right.
A bad job of coding is a sure path to a low grade (but a good job of coding does not necessarily mean a good grade).