If you are working with Plan 9 code, note the following conventions:
Language is idiomatic. If you use the same idioms as everyone else, your code will look natural. If you don't, your code will stand out like an American tourist in a foreign country. If you are writing something common, say it the same way everyone else does. For example, use a < 0 instead of 0 > a and name your loop variables i, j, k, not lv1, lv2, lv3.Comments If your code is readable, you shouldn't need many comments. A line or two comment above a function explaining what it does is always welcome. Whenever you find yourself wondering why some section of the code is the way it is, add a comment, even one that says
/* * BUG explain this. I don't understand why the third parameter is 0 here * rather than -1. I would expect -1 because ... */Put comments on lines by themselves, before the code they explain. Don't use commenting as an excuse for writing confusing code. Rewrite the code to make it clear. Efficiency Do the simple thing. Don't optimize unless the code is measurably slow. Even then, fix the data structures rather than look for little 5% tweaks. CVS We'll probably use CVS, more as a lame distributed file system than as a source code control system. Check-in messages should be a brief summary of what is changing, not an essay. If the code needs comments, put them in the source files (but see above). Critique I may suggest lots of changes to your code, many small, some large. Don't lose heart. That usually means that the code is already good and I want to make it even better: you can't polish a turd. Communication Don't be a stranger. Keep me up-to-date on your status via email and stop by and chat once in a while.