# [Proposal] Remove the tail ws in codes - Thread: https://externals.io/message/57067 - Original archive: https://news-web.php.net/php.internals/57067 - Started by Laruence on 2011-12-24T06:21:40+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #57067 — Laruence — 2011-12-24T06:21:40+00:00 URL: https://externals.io/message/57067#57067 Hi: I noted there are a lot of tail white spaces in our codes, it is better to remove them all, and we also should watch such ws in furture. a simple way to erase such ws in vim, use :%s /\s\+$//g thanks -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #57074 — Rafael Kassner — 2011-12-24T11:09:14+00:00 URL: https://externals.io/message/57067#57074 · In reply to: #57067 AFAIK, PHP files are transformed in bytecode before the execution, so white spaces will not interfere in nothing except more time to transfer the file over SFTP. It's pretty good to implement on our IDEs (and a lot of them is doing it), once trailing white spaces are annoying while we are developing. > Hi: >    I noted there are a lot of tail white spaces in our codes, > >    it is better to remove them all,  and we also should watch such ws > in furture. > >    a simple way to erase such ws in vim, use :%s /\s\+$//g > > thanks > > -- > Laruence  Xinchen Hui > http://www.laruence.com/ > > -- > > > -- Atenciosamente, Rafael Kassner --- ## #57075 — Pierre Joye — 2011-12-24T11:11:30+00:00 URL: https://externals.io/message/57067#57075 · In reply to: #57074 hi! Laruence refers to the PHP C source code and removing trailing white spaces is a good thing as it is part of our CS. Go ahead Laruence :) > AFAIK, PHP files are transformed in bytecode before the execution, so > white spaces will not interfere in nothing except more time to > transfer the file over SFTP. > > It's pretty good to implement on our IDEs (and a lot of them is doing > it), once trailing white spaces are annoying while we are developing. > > > > […] > > > > -- > Atenciosamente, > Rafael Kassner > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57076 — Rafael Kassner — 2011-12-24T11:18:33+00:00 URL: https://externals.io/message/57067#57076 · In reply to: #57075 Oh, shame on my, I was thinking about PHP code. Even so, this is coding standards for PHP C code. Have we this? This can be a good one. > hi! > > Laruence refers to the PHP C source code and removing trailing white > spaces is a good thing as it is part of our CS. > > Go ahead Laruence :) > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Atenciosamente, Rafael Kassner --- ## #57078 — Derick Rethans — 2011-12-24T11:56:32+00:00 URL: https://externals.io/message/57067#57078 · In reply to: #57075 > Laruence refers to the PHP C source code and removing trailing white > spaces is a good thing as it is part of our CS. > > Go ahead Laruence :) Please don't. Changing whitespace en-masse makes it a royal pain to do merges later. Please just fix them when you change the code on that line only. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #57079 — johannes@schlueters.de — 2011-12-24T13:34:35+00:00 URL: https://externals.io/message/57067#57079 · In reply to: #57078 > > > > […] > > Please don't. Changing whitespace en-masse makes it a royal pain to do > merges later. Please just fix them when you change the code on that line > only. It's not only bad for merges, also confusing with blame/annotate while identifying the reason for bug. johannes > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug --- ## #57080 — Laruence — 2011-12-24T13:45:58+00:00 URL: https://externals.io/message/57067#57080 · In reply to: #57079 2011/12/24 Johannes Schlüter : > > > […] > > It's not only bad for merges, also confusing with blame/annotate while > identifying the reason for bug. > hmm, yes, you are right :), actually, I am not saying that I am going to do such behavior, just remind us that we should watch such CS, since there have been lots of tail ws now... :) thanks > johannes > > > […] > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #57081 — Pierre Joye — 2011-12-24T14:33:14+00:00 URL: https://externals.io/message/57067#57081 · In reply to: #57078 > > > > […] > > Please don't. Changing whitespace en-masse makes it a royal pain to do > merges later. Please just fix them when you change the code on that line > only. There is no deal or pain to fix them in all branches at once. There is no need either to do it all at once, but doing them while working on a file in a separate commit before the actual change is just fine and is a good practice. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57082 — Pierre Joye — 2011-12-24T14:33:58+00:00 URL: https://externals.io/message/57067#57082 · In reply to: #57079 2011/12/24 Johannes Schlüter : > It's not only bad for merges, also confusing with blame/annotate while > identifying the reason for bug. Huh, since when do we commit or recommend to commit WS changes with actual changes? -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57083 — Laruence — 2011-12-24T14:42:28+00:00 URL: https://externals.io/message/57067#57083 · In reply to: #57082 Hi: It is necessary that highlight the tail ws in view svn. that can help us avoid adding more tail ws .. :) thanks 2011/12/24 Pierre Joye : > 2011/12/24 Johannes Schlüter : > > > […] > > Huh, since when do we commit or recommend to commit WS changes with > actual changes? > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #57085 — Lester Caine — 2011-12-24T14:55:07+00:00 URL: https://externals.io/message/57067#57085 · In reply to: #57081 Pierre Joye wrote: > > […] > There is no deal or pain to fix them in all branches at once. There is > no need either to do it all at once, but doing them while working on a > file in a separate commit before the actual change is just fine and is > a good practice. I'm with Derek ... having commits that are just WS corrections can be irritating when tracking changes ... but it would most definitely better to get them fixed before moving to git which would lump mass commits like that together in a change set and make rolling back changes a nightmare. Logically it makes a lot more sense simply to leave them alone until such time as a file is touched for other reasons ... and at that time then a separate commit of the WS prior to the bug fix IS good practice. Bundling a whole array of WS fixes across unrelated sections of code is not once you move to any DVCS system. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #57092 — Stas Malyshev — 2011-12-24T20:44:02+00:00 URL: https://externals.io/message/57067#57092 · In reply to: #57079 Hi! > It's not only bad for merges, also confusing with blame/annotate while > identifying the reason for bug. As soon as we move to git, IIRC git has ability to separate ws-changes from non-ws ones and do diffs/history while ignoring ws. I didn't figure out if you can do non-ws merge (I suspect you can since you can do non-ws diff manually and then apply it). So I'd suggest at least waiting till we get git running. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57094 — keisial@gmail.com — 2011-12-24T22:38:49+00:00 URL: https://externals.io/message/57067#57094 · In reply to: #57085 > I'm with Derek ... having commits that are just WS corrections can be > irritating when tracking changes ... but it would most definitely > better to get them fixed before moving to git which would lump mass > commits like that together in a change set and make rolling back > changes a nightmare. Perform that as the last svn commit?