Slot naming convention

Chris Kawa

Out of curiosity - what's the slot naming convention in your projects? Do you name your slots afer what they're supposed to be connected to or after what they do, e.g.

connect(sender, &Button::clicked, receiver, &Foo::onButtonClicked)

or

connect(sender, &Button::clicked, receiver, &Foo::selectSomeStuff)

I have my personal pick, but I've seen strong opinions on both. Qt itself is kinda inconsistent, since it has the second style slots, but also supports the first type with the auto-connect feature. I'd like to see some arguments from more people.

Ronel_qtmaster

@Chris-Kawa Hi.Personnaly, i name my slots after what they are supposed to.Because the code will be more understandable to other users reading it. For exemple

connect(&Button::clicked, receiver, &Foo::onButtonClicked)
connect(&Button::clicked, receiver, &Foo::openFile)

Do you see the difference?In the second option the Developer directly understand what the click on the button involves

SGaist

Hi,

Good question, it depends whether it's an API such as a property where I follow the usual setXXX pattern.

Otherwise, I usually use meaningful names to keep the code easier to read and understand.

JoeCFD

@Chris-Kawa I prefer onButtonClicked. However, as long as the naming convention is consistent in the project, I am ok with it.

Chris Kawa

@Ronel_qtmaster What if slot is simple aggregate of 2 or more things that need to happen on a signal e.g.

void Foo::???()
{
   readConfig();
   openFile();
   logStuff();
   notifySomething();
}

Do you name it Foo::readConfigAndOpenfileAndLogStuffAndNotifySomething or onClick?

@JoeCFD What if you need to connect the same slot to two things, e.g.

connect(button, &Button::clicked, receiver, &Foo::onButtonClicked)
connect(action, &Action::triggered, receiver, &Foo::onButtonClicked)

Do you still name it Foo::onButtonClicked or Foo::onButtonClickedOrActionTriggered. What if same slot can be called by multiple more means?

JoeCFD

@Chris-Kawa Good question. I do not have a lot of scenarios like you described in my app.

I might do the following:

connect(button, &Button::clicked, receiver, &Foo::onButtonClicked)
connect(action, &Action::triggered, receiver, &Foo::onActionTriggered)

onActionTriggered()
{
     onButtonClicked();
}

or
for example, if two different signals triggers the same robot move, I may name the slot

onMoveActivated

If a slot is linked to multiple signals, a generic slot name may be used.

Axel Spoerl

I personally use the onButtonClicked style, when the slot performs something, that is clearly and exclusively linked to the signal and the sender.
onPopupButtonClicked would be an example. In other cases, e.g. where a button causes something to happen, that can also be triggered otherwise, I try to assign the slot a meaningful name, e.g. refreshPageFromDatabase.

I personally find the on_someSender_someSignal - autoconnect naming not very attractive and I try not to rely on autoconnect. It makes life easy at the beginning, but cumbersome if legacy code gets refactored or re-used.

J.Hilk

I usually go with onButtonClicked if the slot is really only called by a single signal.

for example:

QObject::connect(qApp, &QGuiApplication::applicationStateChanged, this,     &Backend::onApplicationStateChanged);

if multiple signals connect to it, or it's called manually, then a clear name for slot is the way to go. And in that case I don't even declare it as a slot:in the header. But a normal privat/pubic/protected function.

SimonSchroeder

I guess we are past regular "slots" by now. With the new connect syntax you can connect to any regular member function and don't have to declare these as slots. Except for tutorials I have never used onButtonClicked as slot names (even with the old connect syntax). A member function should be named after the thing it does. Or phrased differently: The general rule (which might have exceptions) is to name any function (member or freestanding) with a verb (one deviation from the rule could be getters with the naming scheme that Qt uses). (To be more precise: a verb in its imperative, active form.)

@Chris-Kawa said in Slot naming convention:

Do you name it Foo::readConfigAndOpenfileAndLogStuffAndNotifySomething or onClick?

I would use separate member functions that do just a single thing and then have multiple connects. If there needs to be a specific order (which is not guaranteed by connect) I might actually fall back to using onButtonClicked (or a lambda inside the connect) as an exception to the rule, where this might only occur by clicking the button. Triggering the same behavior from regular code (instead of clicking a button) you can still call all 4 functions in order. If this is too cumbersome (and occurs often) you should find a better name for the function. Something that is supposed to be called from regular code should not be called onButtonClicked.

kshegunov

@Chris-Kawa said in Slot naming convention:

Do you name your slots afer what they're supposed to be connected to or after what they do, e.g.

The latter, (almost) universally. A slot is meaningless if you tie it to a specific signal, or to elaborate a bit - a slot is an "action" on the object state of some kind, it shouldn't care to know if a button triggered it or something else, or if it were scheduled manually over the event loop, or w/e.
Generally speaking I use what Qt uses for its API - slots are verbs: connect, stop, etc., while signals are adjectives/adverbials connected(), readyToTransmit() ... you get the point.

If I have a need for a very specific slot that's tied to the emitter I simply use a lambda (or bind it into the private implementation through the dptr, if I'd chosen to employ it, which I usualy do).

mzimmers

FWIW, put me in the camp that prefers meaningful slot names. Slots are functions that presumably do something valuable; what they do should be suggested in the function name, as it is with any other function.