Code review (e.g. use === instead of == where possible.)

I find that a lot of the logic in module_missing_message_fixer_check_modules() is the same as in module_missing_message_fixer_form().
Maybe this should be factored into one single function?

In module_missing_message_fixer_form():

    if (is_null($check) &&
        $record->name != 'default' &&
        !array_key_exists($record->name, $special)) {

better put the && at the beginning of next line, like this:

    if ($check === NULL
        && $record->name !== 'default'
        && !array_key_exists($record->name, $special)
    ) {

This is not an official coding standard yet, but proposed here, #1539712: [policy, no patch] Coding standards for breaking function calls and language constructs across lines.

Maybe even better would be to reorganize the if / else conditions like so:

  // Go through the query and check to see if the module exists in the directory.
  foreach ($query->fetchAll() as $record) {

    if ($record->name === 'default') {
      continue;
    }

    if (array_key_exists($record->name, $special)) {
      // @todo Do something.
      continue;
    }

    $filename = drupal_get_filename($record->type, $record->name, $record->filename, FALSE);

    if ($filename === NULL) {
      // @todo Do something.
      continue;
    }

    // Verify if *.info file exists. See https://www.drupal.org/node/2789993#comment-12306555
    $info_filename = dirname($filename) . $record->name . '.info';
    if (!file_exists($info_filename) || !is_readable($info_filename)) {
      // @ŧodo Do something.
    }
  }

This allows to skip the drupal_get_filename() call for the "special" and "default" modules / profiles / themes.

The previous comment also applies to module_missing_message_fixer_check_modules(). Which is why this stuff should be factored out into a single function.

Patch with lots of changes.
I used git format-patch --stdout 94ae4aa to organize the changes into separate commits.

I would do a PR if we were on github.
I usually mirror my Drupal modules on github as e.g. https://github.com/USERNAME/drupal-MODULENAME, If you want to do the same let me know and I will send a PR.

Includes changes for
#2917732: Code review (e.g. use === instead of == where possible.) (this issue)
#2917754: Broken switch() block in module_missing_message_fixer_drush_help()
#2917756: Replace $module -> $modules in drush_module_missing_message_fixer_fix()
#2917738: Detect if *.info file is missing.

Feel free to do some cherry-picking, if you want to apply only some of those changes.

PhpStorm also complains about html tags, it does not like <center>.
But I don't care, I disabled the HTML inspection.

I so use type safe in Laraval and other JS languages. The reason I don;t do it in Drupal is that the data type is sometimes incorrect in some instances. Case in point, integers as strings is a common theme in Drupal.

Well it depends on the case.
Whenever you compare to a literal string, e.g. $var == 'hello world', replacing == with === does not change the behavior.

On the other hand, if you compare strings to numbers, e.g. $var == 5, then replacing == with === would change the behavior. In this case, to make it more explicit, you can use (int)$var === 5, or maybe even better, (string)$var === '5'. I think it's a matter of taste if you want this.

The PhpStorm / EA Extended plugin understand when it is safe to replace == with ===.
In fact, with my configuration, it complains in both cases, but only if it is safe it proposes to do the replacement.