Ok, so starting now these rules apply:
1) For the types 'string', 'number', 'boolean' and 'function', the '!'
shall be written explicitly.
2) For the types 'Object', 'Array' and 'Function', the '?' shall be
written explicitly.
3) Objects will always explicitly have 'string' as the key. So each
Object in a type definition starts with 'Object. 1) For the types 'string', 'number', 'boolean' and 'function', the '!'
shall not be written explicitly. Rationale: Prepending a '!' to a type means that it is not null. For esp
string, number and boolean, it's weird to have the null value. These
types occur a lot and making the '!' explicit would mean a lot of '!' in
the code.
In an Object with string keys, the '!' looks especially silly:
Object.
(Using undefined or null as a key will change it to 'undefined' and
'null' respectively). Meh, I would rather prefer the opposite, have all kind of types be handled in
the same way. So always writing explicitely the if-nullable state. Rationale: Making a distinction between the different kind of types only
complicates things. Just see how it took us more up to a year to get it
finally. Also would be consistent with the rules 2) to 4) where we also write
explicitely the defaults. Based on the errors we're finding in CC's own externs, I am leaning
towards explicit is best. In addition, it isn't that many extra chars
to type for the clarity provided :). So +1 for always using explicit !/? 2) For the types 'Object', 'Array' and 'Function', the '?' shall be
written explicitly. Null pointers can be a problem. The compiler checks the nullness when
passing an object but not when accessing a member. Keeping awareness of
nullness high is good. +1 +1 3) Objects will always explicitly have 'string' as the key. So each
Object in a type definition starts with 'Object. Rationale: Any other type makes no sense, because in JS the key type is
always a string anyway. +1 +1 4) Each non-constructor function must have a @return declaration. +1 +1