[Qt-creator] Editors/Code-models: new year's resolutions

[Erik Verbruggen]

Hello all,

First of all, to all whom it's applicable: a happy new year! (To all
whom it's not: you can save it for the next one .)

As customary, we made a couple of new-year's-resolutions that I would
like to give you a heads-up on. It is specific to the
editors/code-models area (so if you are not sending us patches, stop
reading now). I could rant about deep personal inflection, but let's
just skip those details. It comes down to just 3 little things, being:

1) For every change/patch that changes behaviour, we will add a test-case.
2) For every change/patch, we will add documentation to the
method/function/variable we touch.
3) For every change/patch that we review, we will -1 it when either (or
both) of the previous items is not present, no matter who submits it.
And you are welcomed to vote us down too, which we'll take seriously.

The ONLY exception is for brown-paper-bag bugs, but for that the we
already has the policy to force the Guilty Party to wear a brown paper
bag for a day. (Brown-paper-bag bugs are those bugs that you find 
shortly before or after a release that are hugely embarrassing, and want 
you to put a brown paper bag over your head in order not to be recognised.)

Clarification (or foot-notes or The Details or whatever you want to call
it) for each item:

1) We have had too many cases where we added a feature or fixed
something, but where we unintentionally broke something else. We all
know that fixing a problem is the easiest when you are into it, so I
think this is a case of QED. Of course, we don't need tests for 
additions of simple getters/setters or for cosmetic/style corrections. 
Oh, and existing tests must all pass, of course.

Now we know that certain changes are very visual. If you have such a 
change, that's fine and it doesn't need a test, as long as the 
infrastructure/logic/etc. has one. If you run into an area which doesn't 
only lack tests, but even the basic infrastructure is not there, then 
please let us know!

2) Let's start with the things we're not looking for: it's the kind of
documentation for a simple getter or setter method that, well, gets/sets 
a field of a class. Instead of that, write an understandable comment on 
why that field is there. Or, when you add/change an algorithm, add a 
comment on why it is there or what it does. We are also perfectly happy 
with references to standard documents (e.g. "[16.3.4] item 3" or similar 
when you are in the C++ parser).

3) I think it's just fair to exchange: the maintainers are expected to
take the responsibility for code in their "allocated" area(s), which
(among things) means that people will knock on your door when things
break down.

Best regards,
Erik.