-
Notifications
You must be signed in to change notification settings - Fork 51
Add rules about exception types naming #31
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes a lot of sense to me 👍
@carusogabriel can you maybe give the implementation a shot?
@Ocramius Two things: Second: Just me fixing manually them is enough, or should we create/search a new Sniff? |
About the suffix, we don't use it within the doctrine organisation, so we better make that clear. I use it for my own projects, but that's a different story. We'd need to create a sniff: enforcing by documentation is not effective. |
The check is possible. The same goes for
This is not possible to check with sniff. |
@carusogabriel Yes, the sniffs are already in my todo list :) Should be done this week :) |
@carusogabriel You can try sniffs in |
@carusogabriel please do :) |
0fe5e6c
to
9cf56ce
Compare
9cf56ce
to
86b9b4b
Compare
<!-- Forbid dead code --> | ||
<rule ref="SlevomatCodingStandard.Classes.UnusedPrivateElements"/> | ||
<!-- Forbid suffix "Abstract" for abstract classes --> | ||
<rule ref="SlevomatCodingStandard.Classes.SuperfluousAbstractClassNaming"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should lines 97 and 101 be moved to other PRs? Or should I add them to the standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I add all of them ‘cause of #31 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok let me document that too then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SuperfluousAbstractClassNaming
and SuperfluousInterfaceNaming
forbid both suffix and prefix. So you should document this or add <exclude>
to ignore the prefix check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greg0ire I guess we want just the suffix here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aaah ok yes, I think that's it, because I saw a lot of Abstract
prefixes in the code.
You always know an exception is an exception when catching it or throwing it, so the Exception suffix is useless, but hard to avoid when you need to group exceptions together, which is why it should be present in abstract exception names. See http://mnapoli.fr/approaching-coding-style-rationally/#the-exception-suffix
86b9b4b
to
82abd7d
Compare
I am still against dropping the |
- :white_check_mark: Abstract classes should not be prefixed with `Abstract` | ||
- :white_check_mark: Interfaces should not be suffixed with `Interface` | ||
- :white_check_mark: Concrete exception class names should not be suffixed with `Exception` | ||
- :white_check_mark: Abstract exception class names and exception interface names should be suffixed with `Exception` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @kukulich said, this isn’t possible 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? You can assume inheritance - when ancestor has the Exception
suffix, this class has too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you're right but:
- Not all exceptions has
Exception
suffix, eg.TypeError
. - You cannot report all bugs in one run with code like
A extends B extends C extends Exception
. You can reportC
in first run andB
in second.
So if you're ok with this, it's possible to check "Abstract exception class names". However, I think it's really not possible to report "exception interface names should be suffixed with Exception
"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove the check mark on that one then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Argh I was too slow, @Ocramius just merged :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greg0ire fixup patch with discussion there please :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay
- Keep the nesting of control structures per method as small as possible | ||
- Prefer early exit over nesting conditions or using else | ||
- :white_check_mark: Abstract classes should not be prefixed with `Abstract` | ||
- :white_check_mark: Interfaces should not be suffixed with `Interface` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
composer.json
Outdated
"squizlabs/php_codesniffer": "^3.2", | ||
"dealerdirect/phpcodesniffer-composer-installer": "^0.4.2", | ||
"slevomat/coding-standard": "^4.4.0" | ||
"slevomat/coding-standard": "dev-master" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Version 4.5.0 was just released :)
We need the new sniffs.
🚢-ing this as-is. If it causes problems, we can revert it, but it is worth trying new naming conventions while we still can 👍 |
You always know an exception is an exception when catching it or
throwing it, so the Exception suffix is useless, but hard to avoid when
you need to group exceptions together, which is why it should be present
in abstract exception names.
See http://mnapoli.fr/approaching-coding-style-rationally/#the-exception-suffix
This is the first of a series of goals I want to clarify regarding exceptions in Doctrine before trying to make a BC version of doctrine/orm#6743
At the moment, things are of course absolutely not like that, but I think that those rules could apply to newly-created exceptions.