[Kde-games-devel] kAtomic, Bug 154756, Patch

[Ian Wadham]

Hi Dmitry,

On Tue, 8 Apr 2008 06:01 pm, Dmitry Suzdalev wrote:
> On Tuesday 08 April 2008 01:04:20 gnushi at web.de wrote:
> > As this is my first patch to KDE, please feel free to tell me if I missed
> > anything.
>
> Yep, I have a couple of notes on board :)
>
> 1. You named actions "prevLevelAct", "nextLevelAct". In KAtomic the
> convention is to use "m_" prefix for member variables (you can tell that by
> looking at other vars in header ;)), so please stick to that. So these
> actions should be named m_prevLevelAct, m_nextLevelAct.
> Reasons to name vars like that - it can easily be seen which var is
> member-var and which is local to some function.
>
Thank you too, Dmitry, for your patient explanations.  I have learned a
lot from them.  One is never too old to learn ... ;-)

> The basic rule when hacking on KDE (as well as other OSS projects) is to
> use conventions that are already there :)
>
Amen to that.  For ALL projects ... Open Source or otherwise.

> <snip>
> can become: nextLevelAct->setDisabled( level == maxLevel )
>
Now why do some people write spaces after "(" and before ")" and no
space before "(" ?  I'm just curious, not wishing to start anything.

In maths I write "cos (a + b)" and the same in programming.  My idea
is to make the function-name and argument(s) separately readable
"words".  Also, in English text, the same rule is followed (space before
parentheses, no space at start and end).

> 7. No need to #include <QTimer> in header - it is needed only in *.cpp
> So move #include <QTimer> to gamewigdet.cpp, and insert a forward
> declaration in gamewiget.h. (you can see how it is already done there for
> KAtomicHighscores class) That's a good habit to have: put only needed
> #includes in .h files, and forward declarations for others. This can save
> you many dependensies between files in future and therefore greatle reduce
> compilation time.
>
Being self-taught in C++ and infected with C, Fortran, COBOL and who
knows what else, I have often wondered what the principle is in this case
- hence the rather chaotic dependencies in KGoldrunner maybe ... :-(
Thanks for the rule and the explanation, Dmitry.

> Thanks for your work! :)
>
And thank you for yours, Dmitry.

All the best, Ian W.