DRAFT document on coding conventions in kde libraries

[Simon Hausmann]

On Monday 06 March 2006 01:51, Friedrich W. H. Kossebau wrote:
[...]
> > > See, it seems not to be used in Qt itself, either!
> >
> > I agree that it's not widely used in Qt, but still:
> > ./network/qhttp.cpp:85:    // private slots
> > ./network/qhttp.cpp:87:    void slotReadyRead();
> > ./network/qhttp.cpp:88:    void slotConnected();
> > ./network/qhttp.cpp:89:    void slotError(QAbstractSocket::SocketError);
> > ./network/qhttp.cpp:90:    void slotClosed();
> > ./network/qhttp.cpp:91:    void slotBytesWritten(qint64 numBytes);
> > ./network/qhttp.cpp:92:    void slotDoFinished();
> >
> > See, connected() would look like a method that returns a boolean telling
> > the caller whether we are connected. On the other hand slotConnected()
> > tells me right away that this is the slot connected (no pun intended!) to
> > the connected signal. Same thing with closed() vs slotClosed().
>
> Hm, this ambigousity could be solved by naming conventions resulting in
> isConnected() and onConnected() :) Or not missing the "//private slots"
> right above.
>
> Oh, did I get onX from Objectpascal or Javascript? Now I remember that
> Delphi forced one to have many "OnX"... Hm. So perhaps for-signal-only
> methods really have some usage patterns? But if my patterns are different
> and I can call such methods directly without need for signal/slot that code
> will really look ugly.
>
> So my vote still: no slotX, no onX, from what I wrote above I think it's
> not really needed and hurts those who do not need to use signal/slots.
>
> Could perhaps someone from Trolltech enlighten us why they choose only to
> use slotX with private slots? After all we do almost adore the rest of
> their api style so they could have a good reason here as well :P

Most of the time (if not always) the slot prefix is redundant. It shouldn't 
make a difference whether a method is called as part of a signal/slot 
connection or from manual code. Take QLineEdit::setText() or 
QLineEdit::copy() for example: There's no point in having a slot prefix 
there. And it would be even worse in terms of consistency to let some methods 
have a slot prefix and others not.

So rest assured that methods prefixed with slot are more than unlikely to 
appear in Qt's public API (try searching for slot in the assistant method 
index). Whatever is used internally as private slot name in Qt is an entirely 
different matter, and in case of QHttp it's simply a set of private slots 
connected to its internal tcp socket. Given that private slots unfortunately 
are semi-visible to the outside (but not considered public API, may disappear 
any time, don't connect to them, not documented, kills your kitten when 
called, etc.) they have to have a slot prefix to disambiguate them and avoid 
accidential connections. With Qt 4.2 they will have an even more obfuscated 
prefix to make it clear they're internal :)


Simon