Fix the issues reported by phpcs

The changes are fine. Maintainers should check if it is good to go or not.

The issue summary should always describe what the issue is trying to fix and, in the case, of coding standards issues, show which command has been used, which arguments have been used, and which report that command shown.

-  $node_type = isset($form['#node_type']->type) ? $form['#node_type']->type : '';
+  $node_type = $form['#node_type']->type ?? '';

The minimum PHP version required by Drupal 7 is not PHP 7. The existing code is correct.

hi @apaderno then is it okey to keep "Use null coalesce operator instead of ternary operator." error message ?

Since the rulesets are not applied to Drupal 8/9/10 code, yes, it is fine.
phpcs does not have setting for the PHP version used by the code, and it cannot even know to which PHP version each rule in the ruleset applies.

Also, the issue summary still needs to be updated, as per my previous comment.

Updated the issue summary with required details.

No standard is passed to phpcs. If I run phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md for the 7.x-2.x branch, I get a longer report.

Resolved all the phpcs warning and error messages.

Thanks for the detailed review @apaderno!

I am going to add a few more points:

-    $sitemaps[$smid]->context = unserialize($sitemap->context);
+    $sitemaps[$smid]->context = unserialize($sitemap->context, ['allowed_classes' => FALSE]);

This is a functional change a has nothing to do with a coding standards. Therefore it must be done in a separate issue if it is needed (preferably also with a test demonstrating the bug you are trying to fix).

   public function testDuplicatePaths() {
-    $link1 = $this->addSitemapLink(array('loc' => 'duplicate'));
-    $link2 = $this->addSitemapLink(array('loc' => 'duplicate'));
     $this->regenerateSitemap();

The fact that the variables are not used anywhere does not mean you can delete the whole statements.

-function xmlsitemap_form_locale_languages_overview_form_alter(&$form, $form_state) {
+function xmlsitemap_i18n_form_locale_languages_overview_form_alter(&$form, $form_state) {
   array_unshift($form['#submit'], 'xmlsitemap_form_submit_flag_regenerate');
 }

This is a functional change a has nothing to do with a coding standards. Therefore it must be done in a separate issue if it is needed (preferably also with a test demonstrating the bug you are trying to fix).

I would also prefer to keep the "one-liners" untouched, as often these have better readability.

@apaderno and @poker10 made required changes in this patch.

I apologize: I meant to give a more complete review the same day I posted my previous comment, but I have forgot to do so.

+    // This page callback outputs the sitemap in chunks using the
+    // xmlsitemap_output_chunk() function. There is no access restriction for
+    // this page because it needs to be accessible to search engine bots and
+    // other automated tools that crawl the site.
     'access callback' => TRUE,
     'type' => MENU_CALLBACK,
     'file' => 'xmlsitemap.pages.inc',
   );

The second sentence is probably sufficient.

-        foreach ($info['bundles'] as $bundle_key => $bundle) {
+        foreach ($info['bundles'] as $bundle) {

While $bundle_key is not used, sometimes foreach loops are written so to document what the array contains. That is not necessarily an issue.

-    return $this->assertFalse($match, $message ? $message : t('HTTP response not expected !code, actual !curl_code', array('!code' => $code, '!curl_code' => $curl_code)), t('Browser'));
+    return $this->assertFalse($match, $message ? $message : t('HTTP response not expected !code, actual !curl_code', array(
+      '!code' => $code,
+      '!curl_code' => $curl_code,
+    ),
+    ), t('Browser'));

The changed code is not the same as the existing code. There is an extra comma, which should not be there as only PHP 8 allow it.

- throw new XMLSitemapGenerationException(t('Could not open file @file for writing.', array('@file' => $uri)));
+ throw new XMLSitemapGenerationException('Could not open file %file for writing.', array(
+ '%file' => $uri,
+ ));

If the t() call is removed, the second argument passed to the exception constructor needs to be removed too, as exception constructors usually expect a single argument: the description of what happened.

-    watchdog('xmlsitemap', 'Files: <pre>' . var_export($files, TRUE), WATCHDOG_NOTICE);
-    watchdog('xmlsitemap', 'Custom: <pre>' . var_export($custom_links, TRUE), WATCHDOG_NOTICE);
+    $files_message = t('Files: @files', ['@files' => '<pre>' . var_export($files, TRUE) . '</pre>']);
+    watchdog('xmlsitemap', $files_message, WATCHDOG_NOTICE);

The second argument passed to watchdog() is not a translatable string. It is sufficient the arguments Drupal 7 core passes to watchdog().

if ($stack > variable_get('actions_max_stack', 35)) {
    watchdog('actions', 'Stack overflow: too many calls to actions_do(). Aborting to prevent infinite recursion.', array(), WATCHDOG_ERROR);
    return;
}

Eventually, those function calls are missing an argument, but I would rather fill a different issue.

-    $this->submit_url = url('ping', array('absolute' => TRUE, 'query' => array('sitemap' => ''))) . '[sitemap]';
+    $this->submit_url = url('ping', array(
+      'absolute' => TRUE,
+      'query' => array('sitemap' => ''),
+    )) . '[sitemap]';

Like other changes introduced in this patch, this change does not make the code more readable.

I would rather suggest maintainers to ignore this issue. Reviewing all the introduced changes is time-consuming and the patch does not seem provided by by someone who has knowledge of how code should be modified.
Changing the code to respect the coding standards can be done when a function is edited for another reason. There is no need to resolve all the coding standards issues in a single issue, especially when the changes are done just to see an automatic tool giving an empty report.

Even the last provided patch still has the same errors. What I reported in my previous comment has not been fixed.

The provided patch file "fix_coding_standards-3355437-23.patch" fixes the reported issue as per comment #21.

@shefali99 Thanks for working on this, unfortunatelly the patch still has multiple issues (selecting only few of them):

-  $term->xmlsitemap['language'] = isset($term->language) ? $term->language : LANGUAGE_NONE;
+  $term->xmlsitemap['language'] = $term->language ?? LANGUAGE_NONE;

We cannot use the Null coalescing operator (used on multiple places in the patch), because we are not going to drop BC intentionally.

-function xmlsitemap_form_locale_languages_overview_form_alter(&$form, $form_state) {
+function xmlsitemap_i18n_xmlsitemap_form_locale_languages_overview_form_alter(&$form, $form_state) {
   array_unshift($form['#submit'], 'xmlsitemap_form_submit_flag_regenerate');
 }

I already commented this change previously as a non-coding standards issue, so this change shouldn't be here at all.

-      throw new XMLSitemapGenerationException(t('Unknown error occurred while writing to file @file.', array('@file' => $this->uri)));
+      throw new XMLSitemapGenerationException('Unknown error occurred while writing to file ' . $this->uri);

This is also unrelated to the coding standards.

-  $batch['operations'][] = array('xmlsitemap_batch_variable_set', array(array('xmlsitemap_rebuild_needed' => FALSE)));
+  $batch['operations'][] = array('xmlsitemap_batch_variable_set', array(array(
+    'xmlsitemap_rebuild_needed' => FALSE,
+  ),
+  ),
+  );

I am not sure this is a correct formatting.

-    $operations['edit'] = xmlsitemap_get_operation_link('admin/config/search/xmlsitemap/edit/' . $smid, array('title' => t('Edit'), 'modal' => TRUE));
-    $operations['delete'] = xmlsitemap_get_operation_link('admin/config/search/xmlsitemap/delete/' . $smid, array('title' => t('Delete'), 'modal' => TRUE));
+    $operations['edit'] = xmlsitemap_get_operation_link('admin/config/search/xmlsitemap/edit/' . $smid, array(
+      '
+    title' => t('Edit'),
+      'modal' => TRUE,
+    ));

That newline with a single quote is also wrong formatting / typo.

------------

D7 contrib modules and D7 core itself contains a lot of coding standard issues and personally I do not think that it is useful to invest so much time in fixing these in the current D7 phase (EOL in Jan 2025). So I agree with @apaderno, that this issue is probably too much (either for contributors and also for reviewers/maintainers). Let's just focus on other issues, where we can still deliver some fixes and improvements. Thanks!