Team Guide
From VT.Prog
Contents |
Simplicity
The ideal solution is not the shortest, but the simplest. The simple solution is more likely to work the first time. It is easy to write, debug and understand. Most problems that seem to have a bunch of special cases can be defeated with the right simple and general solution. It takes experience to know how to find it.
Action
You should always be full of action. Either be reading a problem, writing notes for a solution, writing test data or typing. When reading a problem, you should be thinking of the solution. If you are done writing notes and are waiting for the computer, write test data or read another problem or review your solution. Never pay attention to what your teammates are doing unless asked. Of course, you should know what your teammates are doing. However, you shouldn't be focused on it.
Planning
When working on a problem, plan your solution. This means notes on paper. Rough notes for things that are easy. Detailed notes for the tricky bits. If there are any particular functions or loops or logic that involves some thought, write those out in detail.
This way, when you are on the keyboard you can just type as fast as you physically can.
Horrible is fine
If you don't know the right way to do something, hack something up and learn the right way later.
Need to output something like:
000143
Don't know how to add leading zeros? Fake it.
if (n < 100000) cout << �0�; if (n < 10000) cout << �0�; if (n < 1000) cout << �0�; if (n < 100) cout << �0�; if (n < 10) cout << �0�; cout << n << endl;
Not pretty, not the "right" way, but quick to type, simple and works. That makes it the right way for today.
The corollary is don't use a method you don't understand. Example: don't use mod(%) on a number that could be negative unless you know how it will behave in that case.
There are no practices
Treat every practice like a real contest. Play it to win.
Naming
In general, variable name length should be proportional to the time they are in scope. However, pick a naming scheme and stick with it.
For example, I'll use:
- i,j,k for numeric iteration through things. Example: for (int i=0; i<10; i++)
- I,J,K for object iterations. Example: for (list<int>:iterator I=L.begin(); I!=L.end(); I++)
- M for a global STL map (of a game board, or 2d map or something of that sort)
I'm not saying use my standard, but pick one and stick with it. That way you don't have to look at your code to know what you named something and how you capitalized it. Other than things you use the same way every time, avoid single letter variables.
No Online Debugging
If something does not work, print and get off the damn computer. Grab a colored pen and mark every line that is right (verified as you read it). Every line. Mark the things you need to change in a different color.
If nobody is ready to use the computer (which should be extremely rare), you can break this rule but you must keep it to a bare minimum.
Testing
Write test data. Plan for horrible cases. The judges are trying to destroy you. They will try everything their input description does not forbid. Do they say the numbers are integers? Positive? Negative? Zero? Plan for the largest allowable size and the smallest.
