Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The great coding standards restoration #6004

Open
91 tasks
ghost opened this issue Feb 28, 2023 · 12 comments
Open
91 tasks

The great coding standards restoration #6004

ghost opened this issue Feb 28, 2023 · 12 comments

Comments

@ghost
Copy link

ghost commented Feb 28, 2023

Now that we run phpcs against all core PRs, we should fix all existing coding issues in core to avoid getting so many warnings/errors. This issue (inspired by #3213) will list all files/modules/etc. in core and will have PRs against groups of them to make reviewing easier.

  • core/includes/a*: Issue #6004: Fix coding standards. backdrop#4369 [RTBC]
  • core/includes/b*: Issue #6004: Fix coding standards. backdrop#4370
  • core/includes/c*
  • core/includes/database/*
  • core/includes/d*
  • core/includes/e*
  • core/includes/f*
  • core/includes/[g-i]*
  • core/includes/[l-m]*
  • core/includes/p*
  • core/includes/[s-t]*
  • core/includes/transliteration*
  • core/includes/u*
  • core/modules/admin_bar
  • core/modules/block
  • core/modules/book
  • core/modules/ckeditor
  • core/modules/color
  • core/modules/comment
  • core/modules/comment/views
  • core/modules/config
  • core/modules/contact
  • core/modules/contextual
  • core/modules/dashboard
  • core/modules/date
  • core/modules/date/views
  • core/modules/[dblog,email]
  • core/modules/entity
  • core/modules/entityreference
  • core/modules/field_ui
  • core/modules/field
  • core/modules/field/modules
  • core/modules/field/[tests,views]
  • core/modules/file
  • core/modules/file/views
  • core/modules/filter
  • core/modules/image
  • core/modules/installer
  • core/modules/language
  • core/modules/layout
  • core/modules/layout/includes
  • core/modules/layout/plugins
  • core/modules/layout/[templates,tests]
  • core/modules/link
  • core/modules/locale
  • core/modules/local/views
  • core/modules/menu
  • core/modules/node
  • core/modules/node/views
  • core/modules/path
  • core/modules/redirect
  • core/modules/search
  • core/modules/search/[templates,tests,views]
  • core/modules/simpletest
  • core/modules/simpletest/tests/[a-b]*
  • core/modules/simpletest/tests/c*
  • core/modules/simpletest/tests/d*
  • core/modules/simpletest/tests/[e-f]*
  • core/modules/simpletest/tests/[g-m]*
  • core/modules/simpletest/tests/[n-s]*
  • core/modules/simpletest/tests/t*
  • core/modules/simpletest/tests/u*
  • core/modules/syslog
  • core/modules/system
  • core/modules/system.system.[a-m]*
  • core/modules/system.system.[n-z]*
  • core/modules/taxonomy
  • core/modules/taxonomy/views
  • core/modules/telemetry
  • core/modules/translation
  • core/modules/update
  • core/modules/user
  • core/modules/user/tests
  • core/modules/user/views
  • core/modules/views_ui
  • core/modules/views
  • core/modules/views/handlers/views_handler_a*
  • core/modules/views/handlers/views_handler_field*
  • core/modules/views/handlers/views_handler_filter*
  • core/modules/views/handlers/views_handler_[r-s]*
  • core/modules/views/includes
  • core/modules/views/plugins/views_plugin_a*
  • core/modules/views/plugins/views_plugin_[c-d]*
  • core/modules/views/plugins/views_plugin_[e-q]*
  • core/modules/views/plugins/views_plugin_[r-s]*
  • core/modules/views/templates
  • core/modules/views/tests
  • core/modules/views/tests/[handlers,plugins,styles]
  • core/profiles
  • core/themes
  • [misc.]

Anyone wanting to make a PR should:

  • Setup their local with phpcs installed and Backdrop's Coding Standards repo one directory above Backdrop core (I personally use Lando)
  • Run phpcs from Backdrop's root directory like so: phpcs --basepath=. --standard=../phpcs/Backdrop core/includes/a* (change the last bit to match whatever group of files you're targeting)
  • Create their PR with the following description: For https://github.com/backdrop/backdrop-issues/issues/6004 (avoiding any keywords that automatically link the PR to this issue and therefore result in closing this issue when the PR is merged)
  • Edit this issue to add a link to your PR next to the appropriate item above
@ghost
Copy link
Author

ghost commented Feb 28, 2023

One down, a zillion to go!

@izmeez
Copy link

izmeez commented Oct 18, 2023

Just started to look at core/includes/c and in the first file cache-install.inc encountered 9 problems all related to Visibility must be declared on method. I did a quick search and cannot find information to help figure out what is expected here to fix it. Any help is appreciated.

@izmeez
Copy link

izmeez commented Oct 18, 2023

I found this page but I am still not able to decipher what is needed,
https://www.php-fig.org/psr/psr-12/#44-methods-and-functions

@argiepiano
Copy link

This is solved by adding a visibility qualifier in the method declaration such as public, protected or private.

@izmeez
Copy link

izmeez commented Oct 18, 2023

So since all these 9 problems are contained within class BackdropFakeCache extends BackdropDatabaseCache implements BackdropCacheInterface { within which it is not clear where the method declaration is, where would a fix be added?

@izmeez
Copy link

izmeez commented Oct 18, 2023

I have found some more specific details here, https://www.php.net/manual/en/language.oop5.visibility.php

@izmeez
Copy link

izmeez commented Oct 18, 2023

This link provides more details, https://stackoverflow.com/a/4361582

You use:

public scope to make that property/method available from anywhere, other classes and instances of the object.
private scope when you want your property/method to be visible in its own class only.
protected scope when you want to make your property/method visible in all classes that extend current class including the parent class.

If you don't use any visibility modifier, the property / method will be public.

Thus, since nothing was used before it is probably safe to add public to each of the functions like public function get($cid) {

@izmeez
Copy link

izmeez commented Oct 18, 2023

I guess this is a time that now a visibility qualifier is being added the code can be "improved" by selecting some thing other than "public" where it might be appropriate. I don't have the depth of knowledge to make that determination.

@bugfolder
Copy link

If the function was previously implicitly public, then it would seem that when visibility is made explicit, it should also be public in the interest of backward compatibility.

Some functions might warrant a change in visibility to private or protected, but since that would have B/C implications, it should be raised in a separate issue to discuss the implications, and shouldn't be a blocker for this issue.

@izmeez
Copy link

izmeez commented Oct 18, 2023

Maybe, the place to raise that would be once there is a pull request. Although there may be a number of instances.

@izmeez
Copy link

izmeez commented Oct 18, 2023

I also noticed there are other qualifiers like static that may accompany these, such as public static.

@izmeez
Copy link

izmeez commented Oct 18, 2023

Should I start a PR with what I have done so far even though it is incomplete? So others don't jump into doing the same one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants