Is there a reason to emit a Qt signal if there is no slot connected anywhere in the code?

user_10220506 0
Viewed 366

I am new to Qt and have taken over a project from a developer who left our company. I see several places in his code where a signal is emitted, but there is no connection to a slot or other reference in the code to the signal. Is there a reason to do this that I am unaware of?

I have searched through the code trying to find anything that would reference the signals being emitted, but I cannot find anything other than the code that does the emit.

//from the header file
signals:

    void newInstance();

void SingleInstance::newConnection()
{
    emit newInstance(); // this is not referenced anywhere else in the project

   qDebug() << "New connection loading...";
   mSocket = mServer.nextPendingConnection();
   connect(mSocket,SIGNAL(readyRead()),this,SLOT(readyRead()));
}

There are no errors and the application runs fine. I am just trying to see if there is something I am missing because of lack of experience with Qt.

qt5 qt c++
3 Answers

One could ask: Why stop at your application? Qt provides lots and lots of signals that are not used anywhere either - neither your application uses them, nor do the Qt modules that you likely use need them. Would you wish to remove those signals? Why not?

In typical Qt applications, most signals are not connected. That's by design: the signals are there to indicate "interesting" situations, that might be useful to someone. Whether the "someone" is there to use them (connect to them) is not a given. Signals and slots are means of decoupling software elements: when designing an API (e.g. a class), you might wish to provide relevant signals that might be of use later.

Signals in your application code, that happen not to be connected, shouldn't be immediately thought of as being redundant. Think of why would the author of that code include these signals. They might have had a need for them that has now passed (look in the git history around the time that code was added and see if any references to these signals were added as well, but later removed) - in this case you might consider to remove the signals. But this is a rather narrow case, and you should first understand the design intent that the signals represent. Assuming a competent team, those signals were put there for some reason. Understanding that likely reason (or reasons) is the prerequisite to changing the code. This is the case with any code, not only with signal definitions.

Also: make sure that no other projects within your organization depend on the repository that holds the code you're using. Someone could be using it as a git submodule, for example. And they may be using those signals. You need to make sure before you start removing functionality.

user_13296520

It depends on the intention. If you do not use you can delete.

user_56131640

  1. Signals express a situation that may be worth handling or reacting to. It is optional to connect to them.

  2. Signals, as well as the rest of the API, is a contract. You cannot change the contract without breaking functionality.

If you stop emitting the signal, part of a project depending on such module may fail (or just stop working as intended, which may be worse and harder to detect). You should in this case document it, change API version...

If not emitted at all anymore, you should remove the signal declaration too (or marking it someway deprecated), so, at least, compilation will fail in depending modules (if using the Qt 5 syntax, if still using the SIGNAL macro it will be harder to detect, and in real-time only).

Obviously, it's not the same the API of a base-level module, than a class in a top-level project that no one depends on and where you have full control.

user_14858850
Related