Hallo Martin,
Das ist durchaus eine "good practise".
Ich würde das sogar als eine Nutzungsvorschrift sehen. Aus genau dem Grund, den Du genannt hast.
PSR-1 formuliert das so:
Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
Eine includete Datei, die Code enthält und auf ?> endet, produziert mit 99% Sicherheit einen Output hinter dem ?>, es sei denn, man hat einen Editor mit dem man tatsächlich den Zeilenumbruch hinter dem letzten ?> entfernen kann; die sind seltenst zu finden. Möglicherweise war die second.php mal so getrimmt, dass hinter dem letzten ?> nichts mehr kam. Und nun, beim Kopieren oder einem unachtsamen Editieren, ist ein Linefeed hineingekommen, der nun das PDF ruiniert.
Output hinter einem ?> am Dateiende kann in seltenen Fällen unschädlich sein, zumeist ist er aber eine Spaßbremse.
Für Jörg ist aber auch die Frage: ist der PHP Code in second.php "lokal"? Oder werden da Funktionen deklariert, die auch außerhalb von second.php genutzt werden? In dem Fall gehört das Ding geteilt, nach den Maßgaben von PSR-1. Das ist ein durchaus sinnvoller Coding-Styleguide für PHP.
Wenn alles PHP im second.php aber nur innerhalb von second.php genutzt wird, dann ist das ok - weil es dann ein include "with side-effects" ist.
Ein Include, das Funktionen für übrige Programmteile bereitstellt, muss gemäß PSR-1 aber nach außen hin "stumm" sein, d.h. außer dem Erstellen von Variablen, Funktionen, Klassen und Konstanten darf es nichts tun. Das gilt natürlich nicht für die Inhalte der Funktionen und Methoden in den Klassen. Wenn die aufgerufen werden, aber nur dann, dürfen sie sich austoben.
Rolf
sumpsi - posui - obstruxi