Revert coding style changes to system.tar.inc & other externally developed files

subscribing...

I made a similar point in #861566-4: Use uppercase for PHP constants, e.g. NULL, TRUE, FALSE, now closed in favor of this one.

+1

I totally agree with sun and Damien.

Agreed.

And then, can folks who care about code consistency please spend time on some kind of fancy Drush / Coder integration for "drush coder-format --fixelseif --fixnewlines" and whatnot that's smart about exempting this sort of upstream code, and which maintainers can then run at their leisure, rather than wasting a bunch of actual human brains on this problem every couple of months?

@webchick: to be honest, I'm slightly tired of reviewers rejecting patches for trailing new lines and stuff like that.

Damien: Me too. If we had drush coder-format --fix-whitespace, core committers could just run that prior to committing any patches, and we'd fix them at commit time (or, failing that, at release time). I'm 100% in favour of not wasting human brains on whitespace issues.

sun: I know, which makes it even worse because someone had to manually craft those, and someone else had to review them one. line. at a time. So heart-breaking. :(

I'm not sure where Coder's at atm, but solotandem would be a good person to ping on IRC.

The patches I proposes are based on the last commits done to the file, right after my previous patch in #850152: Use "elseif" in place of "else if" was applied. I was referring to revision 1.2 (the revision of the file system.tar.inc, not the original one) as the revision to which revert the file content.

I attach here the patch that would revert the file back to revision 1.2, which is the revision without any style changes. It's not the first revision of the file, though.

totally off topic
--------------

To all:

I'm not a git expert, but I read that there are some git options to adjust a file while getting updated with some kind of script that can replace tabs with spaces, add newlines, ...
99% of our patches could use such a script. 1% sadly need "/no newline at end of file" or other "errors" (for testing purpose, or for other causes).

If we transfer to git it maybe would be an idea to add a checkbox somewhere around the upload patch button which says: "check and convert to our coding standards".
That way me or someone else don't have to nitpick any more (I hate it to).

ps: optional we could let the uploader now what was wrong in his patch so he could learn some coding standards in a more automated way.

on topic
--------
let's review 11

I looked at the original report opened by chx, and I noticed that he changed the code to decouple it from PEAR.
In that case, what is the difference if the code has been changed to fit our coding standards? If we need to update the code to the latest code developed for the original file, we still need to change the code to decouple it from PEAR.

On aspilicious's OT remark, I'm fine with teaching people coding standards. I am NOT okay with human coders/reviewers wasting braincells on trailing whitespace and extra newlines at the end of files. Let computers worry about that.

Back on-topic, this is needs work, per #13.

Which kind of changes should be commented? Shall we comment all the changes, including the ones done to decouple the code from PEAR?

The attached patch documents the changes done from our revision 1.1 to 1.2; it also avoid the original CVS tags are replaced by removing the $ at the beginning, and end of the orginal CVS tags.

I will submit a different patch that contains the code removed from the original file as comments.

I took the approach taken in the back port of SimpleTest for Drupal 6.

I added the comment // Drupal integration. in two places.

Committed to HEAD.

Opened related #1298304: [Meta] Move all externally-developed files to core/vendor/{vendorname}/ directories