[#15814] - Document use of @ error suppressor
- Fixed in Code Base
- 5 May 2017
- Medium
- Build: staging
- # 15814
- Diff
- PhilETaylor:supressordocumentation
User tests: Successful: Unsuccessful:
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Labels |
Added:
?
|
||
| Title |
|
||||||
True - moved to docblock now
I have just also added the missing *. Thanks.
cool no worries.
I just dont want someone (aka without experience/without context) seeing all the error suppressing, and refactoring it in the future...
I have tested this item
I believe you have an extra blank line - @zero-24 might want to correct that?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15814.
I have tested this item
For me it is OK
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15814.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15814.
| Status | Pending | ⇒ | Ready to Commit |
RTC after two successful tests.
@PhilETaylor please provide at least one sentence to explain what this is about, will make my life a bit easier
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-05 16:30:43 |
| Closed_By | ⇒ | rdeutz | |
| Labels |
Added:
?
|
||
It will make no difference whatsoever to you or your life... now.
In 2 years time when some newbie refactors or removed the @ supressor and all hell breaks loose, then you would have been grateful of notes to stop a newbie refactoring/removing @ suppresors.
In my life, EVERY SINGLE use of an @surpressor should be documented as to why its being used, as 99% of the time you are doing something wrong if you are using one. This use case is one of the 1% where its perfectly ok to use it, documenting that is better too.
Like many experienced developers - I have wasted hours and hours debugging issues hidden by someone just using @ all throughout their code without knowing what they were doing.
Notes/Documentation that stops developers in 2 years misunderstanding and creating issues is also a good thing. How many times has Joomla released bugs based on flawed understanding of the original intentions.
What are you talking about? I asked for one sentence explaining what this PR is about.
add inline documentation so that someone doesn't refactor to remove @ error suppression in the future.
a one line description as requested ;)
What are you talking about? I asked for one sentence explaining what this PR is about.
No you never. You made no reference to "the PR" ... One assumed you meant you wanted to know generally what it was about.
So when I receive an email from you, out of context, how am I meant to know what you want :)
As title says?...
When I comment on a PR I am usually not speaking about the football match last weekend :-) Anyway, I hope you got the point.
Anyway, I hope you got the point.
That you were too lazy to read. Yup. Got that thanks.
Seems not so I need to explain it a bit more. You added a link to another PR, why you made this PR was part of a discussion within the PR. So I had to figure out why you made this PR. Check if the intention and the PR are inline. I did it and I merged the PR. If that is lazy, then I don't know.
isn't this comment true for all 3 usages of the @ in that method?