I finally decided that it's best to remove all ?> from the end of all files. I set this to ready to be commited as there is not a single line of code which is modified and we have debated this to death on the devel list.

TODO: update the coding style guidelines.

CommentFileSizeAuthor
#3 leftovers.patch1.77 KBchx
no_question_more_at_the_end.patch20.22 KBchx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Uwe Hermann’s picture

Patch applies, seems to work (a quick check trying various things on a test-site succeeded).

Dries’s picture

Status: Reviewed & tested by the community » Active

Committed to HEAD. Marking this 'active' until the coding guidelines have been updated.

chx’s picture

Status: Active » Reviewed & tested by the community
FileSize
1.77 KB

I have not patched *.php so that templates won't get hurt. But this meant a few files are left out... here.

Thomas Ilsche’s picture

What do you think about leaving a comment at the end of every file like

// end tag intentionally omited

should ease the entrance to new users, prevent confusion, issues...

Uwe Hermann’s picture

+1. This will prevent lots of questions in the forums...

Morbus Iff’s picture

No, it won't. It'll just turn "why is the thing missing" to "so, uh, what's the reason it''s missing?" Intent has nothing to do with explanation. If we include a comment like this, we should include a page in the docs explaining exactly why, and then include that URL in the comment. Only then will it pre-empt questions.

webchick’s picture

Even better would be something like:

// end tag intentionally omitted - see http://lists.drupal.org/archives/drupal-devel/2005-08/msg00648.html

Note: 2 "t"s in omitted.

This would stop both the "Hey, you guys forgot to put ?>s at the end of your files!" as well as the "Hey, WHY is the end tag intentionally ommitted?"

The only problem is that's now an extra ~100 bytes X however many core files there are + contrib module files, etc.

I agree that this information definitely needs to be available (and in a very prominent place) in order to address forthcoming questions/concerns, but I'm not sure if appending to the end of each file is necessarily the best way...

kbahey’s picture

Angela.

I was just thinking the same thing.

A better arpproach would be to summarize the mailing list dicussion to a Drupal.org page in the FAQ section, and point to it.

// End PHP tag intentionally omitted. See http://drupal.org/faq/something for details.
nedjo’s picture

An FAQ addition is a good idea, but I think we can safely document and not append a message. The same message in every file is bloat (unless it's needed for e.g. licensing). People will figure it out.

Morbus Iff’s picture

Well, if we're not gonna have an explanatory message inline, I'd prefer something like:


// 

commented; see http://drupal.org/faq/tricky_code_that_requires_explanation

?>

Note: I'm still not a fan of this ;)

Morbus Iff’s picture

Grr. Well, that screwed up. Sure wish Preview worked ;) Let's try this:

// ?> http://drupal.org/faq/tricky_code_that_requires_explanation

chx’s picture

Folks, this is simply silly. Next what, we add a comment to every single SQL query explaining what's {} around the table names? (It's not in the db_query docs, it is in db_prefix_tables.)

Or we begin to pick label some features of the PHP language as "strange" and comment them like no tomorrow? For example the "alternative syntax" in templates? Heredoc syntax (if we use that at all)? Write lengthy essays about what our pregs do just because they are hard to understand? Forget this but please commit my patch :)

Morbus Iff’s picture

chx: ANY tricky code needs to be commented. If a piece of code makes you go "hmmm...", then yes, it needs to commented. Unlike, however, our internal documentation which can be traced to a solution (for your bracket/SQL example), there is no traceable way to find why the ?> is missing. Sure, I could spend an hour Googling around, just like I could spend a month reading everything about regexps to try and decipher what the hell is going on with an uncommented core regexp. But this is why every language has a commenting feature: to explain tricky code. This code is "tricky" because it makes people ask questions, it is not immediately obvious, nor has it affected every single user out there. Likewise, it's certainly not a popular snippet that can be seen in tons of other pieces of PHP coding.

Likewise, you talk about this like it's some sort of major feature that everyone should be aware of. If we go back to Gabor's page on php.net (http://us3.php.net/basic-syntax.instruction-separation), you'll notice that it is merely a "Note". If this were really a full-fledged feature, as opposed to just "something you could do", it'd be a lot more than a "Note". A "Note" is something you say "Oh, yeah, you could also...", a side effect, a clarification of something else entirely.

And finally, Gabor's page, assuming people do find it by browsing through Google, doesn't even explain why WE, Drupal, are choosing to do this - it's an off the cuff "oh, yeah, it's optional, and occasionally useful when you use includes". The impression people will get is that it's an optional stylistic trick, NOT that it is actually fixing a bug. Because of this, it'll become equivalent as check_markup: few third party modules will actually use it because no one understands WHY they should.

Dries’s picture

Status: Reviewed & tested by the community » Fixed
Gábor Hojtsy’s picture

Status: Fixed » Reviewed & tested by the community

Morbus, your points are mostly valid, but the solution is not to add bloat to every file. We have some coding guidelines. That states where should parenthesis go, where you should use two spaces, alternative control structure syntax, etc. Omitting of the closing tags is a similar matter, plus it solves issues. It should be documented in the coding guidelines. If people find this pattern, they will (at least should) look into the guidelines. It is not that any piece of the guidelines should be included in every file.

Watch out for my "omitting T_CLOSE_TAG" thread on php.internals, I hope it is going to catch on, so I can clarify the PHP documentation.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed
kbahey’s picture

Here is an example of how much confusion this can cause:

In issue http://drupal.org/node/30054 the patch attached has at the end:

-?>
+?>
\ Kein Zeilenumbruch am Dateiende.

That bit in German is automatically added (no newline at end of file?), and is not the issue.

The important point is that the user had to edit the file and add the closing tag, thinking it is missing.

Gábor Hojtsy’s picture

kbahey, that -/+ does not mean he added the "missing" closing tag, it means it wsa there already (or therwise the minus would not be there), but his editor automatically removed the trailing newline at the end of file. This is typical.

Anonymous’s picture

Anonymous’s picture

ax’s picture

Version: » x.y.z
Status: Fixed » Active

marking ACTIVE again as the

TODO: update the coding style guidelines.

apparently hasn't been done yet.

(just for the record: i didn't follow this issue, and i was *quite* confused after i cvs-updated my Drupal and found many ?>s missing. did someone mess with the repository? strange line endings issues? ...

all in all: loss of some work hours, and, imo, quite a strange move)

webchick’s picture

Status: Active » Fixed

I've updated both CODING_STANDARDS.html in the contrib repository, and added a note to http://drupal.org/node/545 (PHP Code tags). The Coding Standards handbook page should be updated shortly, as soon as Dries can get to it.

Anonymous’s picture

Status: Fixed » Closed (fixed)