*kiss*
This is great.
> *Check for errors early and often. Every time you make a call into an
> XPCOM function, you should check for an error condition. You need to
> do this even if you know that call will never fail.
Okay, I'm gonna draw a line in the sand and claim that this is way too
facist. Why? Because you know and I know that we over-use COM in an
obnoxious way. I think that judgement needs to be exercised here.
> *Return from errors immediately Every time an error condition
> happens, your knee-jerk reaction should be to return from the current
> function.
See above. Use judgement when propagating errors to the caller.
> *Use NS_LITERAL_STRING() to avoid runtime string conversion. It is
> very common to need to assign the value of a literal string such as
> "Some String" into a unicode buffer. Instead of using nsString's
> AssignWithConversion and AppendWithConversion, use NS_LITERAL_STRING()
> instead. On most platforms, this will force the compiler to compile in
> a raw unicode string, and assign it directly.
[snip]
Even More Correct:
NS_NAMED_LITERAL_STRING(kDanger, "danger will robinson!");
..
// if you'll be using the 'kDanger' string, you can still use it as
before:
foo->SetUnicodeValue(kDanger.get());
(Assigning it to an nsAutoString incurs an unnecessary copy.)
> Naming and Formatting code
>
But, above all, FOLLOW LOCAL CONVENTION! Your job is not to proselytize
Your Favorite Style. Your job is to make it easier on the next person
that has to work on the mess. This applies to:
- Tab stops. 2, 4, 8. We've got all flavors. Use the same settings
that are in use in the file. (The only time you are allowed to
``fix'' tab stops is when you are undoing travis brain damage.
I'm serious, that's okay.)
- Open-curlies. Are they on the same line as the |if|
(or |while| or |else|)?
if (foo) {
vs.
if (foo)
{
- Spaces in parenthesized expressions.
if (foo && (bar == 12))
vs.
if ( foo && ( bar == 12 ) )
- Methods and function prototypes.
void foo(int a, char b, int c);
vs.
void
foo(int a, char b, int c);
- Comparison to null
if (p && !q)
vs.
if (p == nsnull && q != nsnull)
vs.
if (nsnull == p && nsnull != q)
This is not art class. You will not be graded on your creativity. Just
pay attention and do what whoever wrote the file in the first place did.
Make it easier on the poor sap who has to come along later and fix the
bugs that you've just unknowingly introduced.
> *Follow naming prefix conventions Variable prefixes:
>
> * k=constant (e.g. kNC_child)
> * g=global (e.g. gPrefService)
> * m=member (e.g. mLength)
> * a=argument (e.g. aCount)
Please send this via special dispatch to joki when you write it! :-)
Some other random rants.
* This Isn't Pascal. So don't compare boolean expressions to
PR_TRUE or PR_FALSE.
wrong: if (PR_FALSE != IsElbowInEar()) { ... }
right: if (IsElbowInEar()) { ... }
* Don't Edit Generated Files. Is there a big warning at the top of
the file that says ``Do not edit, this file is generated''? If so,
_don't_ edit the file. Edit the file that it was generated from.
