Conversation
| - The application finds files in the source code you provide and registered | ||
| Rectors - from `--set`, `--config` or local `rector.yaml` | ||
| - Then it iterates all found files and applies relevant Rectors to them. |
There was a problem hiding this comment.
Avoid line breaks as it mall-formats on various dimensions (pc, smart phone mobile...). Let browser handle it.
There was a problem hiding this comment.
The line breaks are not taken into account while displaying the rendered html README, this is just for source code and diffs, you can check that by clicking "Display the rich diff"
There was a problem hiding this comment.
What is the reason then?
It's very hard to read and add extra work to control spaces everytime case content changes.
There was a problem hiding this comment.
The reasons are making diffs easier to read, reducing the risk of conflicts, allow displaying the file side by side with another. Actually I wrote an entire blog post about that: https://dev.to/greg0ire/why-i-keep-pestering-everyone-about-long-lines
Also, it can spare you from having to scroll horizontally when reviewing (there is no wrapping in the editor on Github), and is just easier for humans to read when displayed in an editor and no wrapping occurs.
I would agree that for some lines that are a bit long but not that much, the benefits are not huge though. If you are still not convinced just tell me, and I will just drop that commit. For the other PR, it would be harder though, and the benefits a more visible (the lines are so long there that it is more worth it, also there is some code that really benefits from not having a horizontal scroll).
There was a problem hiding this comment.
If you automate it, I don't mind. But I don't want to add extra maintenance cost.
There was a problem hiding this comment.
I don't know of a way to automate that, be it for md files php files or any file, so I'll just drop the commit I guess.
There was a problem hiding this comment.
FYI, In PHP there is: https://github.com/symplify/coding-standard/blob/master/src/Fixer/LineLength/LineLengthFixer.php
It would me madness to ask developers to do it manually.
There was a problem hiding this comment.
Good to know, but I don't know any fixer for markdown.
It would me madness to ask developers to do it manually.
I don't know, I feel humans might often be better than robots at this, because they will split a line where it is meaningful to do so. Plus there are tools built in IDEs to make it a bit less manual I think
There was a problem hiding this comment.
It's about the 0-entrance cost adoption. If you add CI tool, I don't mind and the change would be accepted.
There was a problem hiding this comment.
Also, this PR is self-example of how human suck in these tasks (me in my English :D)
greg0ire
force-pushed
the
proofread-docs
branch
from
0f73783 to
d656490
Compare
greg0ire
force-pushed
the
proofread-docs
branch
from
d656490 to
a5e72f5
Compare
|
Thank you 👍 |
rectorphp/rector-src@baf8394 Fix var/property usage for RemoveUnusedNonEmptyArrayBeforeForeachRector. (#3040)
rectorphp/rector-src@baf8394 Fix var/property usage for RemoveUnusedNonEmptyArrayBeforeForeachRector. (#3040)
rectorphp/rector-src@baf8394 Fix var/property usage for RemoveUnusedNonEmptyArrayBeforeForeachRector. (#3040)
2 participants
No description provided.