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

Consider disallowing use of use function... #158

Open
mikeselander opened this issue Dec 6, 2019 · 6 comments · May be fixed by #188
Open

Consider disallowing use of use function... #158

mikeselander opened this issue Dec 6, 2019 · 6 comments · May be fixed by #188
Assignees
Labels

Comments

@mikeselander
Copy link
Contributor

In line with https://github.com/humanmade/Engineering/pull/143, I propose that we add a rule dis-allowing the use of use function.

As noted by Joe in https://github.com/humanmade/Engineering/pull/143#issuecomment-560330827, this will break linting for several current projects. I personally feel that this is worth it as the rule can be ignored on current projects and it will enforce properly on all new projects.

@mikeselander
Copy link
Contributor Author

As a note, I've added this as a request for a custom sniff here: PHPCSStandards/PHPCSExtra#1

@rmccue
Copy link
Member

rmccue commented Apr 1, 2020

Upstream looks complete here, and +1 on the rule itself.

@mikeselander mikeselander linked a pull request Apr 6, 2020 that will close this issue
@mikeselander mikeselander added this to the 1.0.0 milestone Apr 6, 2020
@mikeselander mikeselander self-assigned this Apr 6, 2020
@joehoyle
Copy link
Member

joehoyle commented Apr 7, 2020

I'm -1 on the enforcement of this rule. I think the guidance we have "should be avoided." is enough. I find the rational for avoiding weak, but ok to recommend. Outright disallowing it I think is too far. This will invalidate a good amount of code that has already been written, that doesn't cause problems, whereby proceeding with this will cause uneccesary churn on existing code.

@rmccue
Copy link
Member

rmccue commented Apr 7, 2020

According to Sourcegraph we have about 1200 instances of this right now. 400 of those alone are in one project, followed by about 200 in another client's projects (namely in the shared workflow repo).

That's not terrible, but it's not nothing either. But I am strongly against "should be avoided" rules generally; it should be binary, otherwise there's no real point having the rule.

@joehoyle
Copy link
Member

joehoyle commented Apr 7, 2020

How difficult would be a phpcbf rule to fix these?

@mikeselander
Copy link
Contributor Author

This will invalidate a good amount of code that has already been written, that doesn't cause problems, whereby proceeding with this will cause uneccesary churn on existing code.

I think there's two paths forward for this rule for projects:

  1. new projects get this rule and there's no mistaking that doing this is discouraged when writing new code. I think this is important because very few of our developers read the Handbook on an ongoing basis so a rule in the coding-standard set is the only way they might know of this change. We can write a P2 post on this, but even that is unlikely to be read and sink in for most developers as people need to see or hear something 3-7 times before it sinks in.
  2. Existing projects can either adopt this rule and fix their code progressively or turn the rule off and fix as they deem fit.

Filtering Sourcegraph by active clients only, I can only identify 3 clients who are using this:

  1. the largest usage will likely turn this rule off and that's fine; they're mostly off our services and Theo is fully capable of fixing these if he feels like it later on.
  2. The second most is led by @fklein-lu, whom I imagine already has a plan in place to fix these.
  3. The next has only 24 occurrences of this so the code churn will be quite minimal.

The non-active clients who have this rule all have less than 60 instances with all but one having less than 40. I don't think code churn is a big problem at that rate.

@ntwb ntwb removed this from the 1.0.0 milestone Feb 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants