We had a strict style-guide. In the general case, this was a Good Thing. If you have a style-guide you can open a file anywhere in a system and you have a familiar environment, variables are named the right way,
But we also had a strict style that meant a 'normal' PHP source file looked like this (this is an 'include' file, not a PHP script that is accessable via a url).
echo "This is the contents of the table";
// This line must be the last line in the file with no following whitespace
Well, yes. That's the code. God. I wish that was a joke. Let me walk through a few of the 'interesting' bits here...
<?php was the start of every file. No file used PHP interpolated with HTML code. Ever.
Yes, all HTML was printed using 'echo'. All of it.
Now, $ColC is the doozy. I couldn't make this up. In a database there was a table that included every CSS class we had created, the idea was that you could through a web based form maintain the CSS stylesheets. Every CSS class had styles for things like Table Cells, Headers and Paragraphs. In order to make this easier to use, each CSS class was inserted into the global namespace as a PHP class instance.
'$ColC' was a name that came out of a database and was dynamically assigned to a global variable in order to make things easier.
I had a vim macro that would produce the 25ish style classes that I would put at the top of every function, it saved programmer time in the long run not having to worry about changing '
global $ShadeL;' to '
global $ShadeR' to the top of a function when I wanted to have a shaded table cell that was Right aligned as well as the Left aligned one.
He whipped up a system that used a templating engine anyway. He didn't believe that that kind of response really mattered in the long run. Templating systems are just how you write code so that it's not entirely unmaintainable. But no, he was told to rewrite the system to follow the coding standards.
Going back to the example cited above, The last two lines are verbatim what you would expect to see in the codebase. There was a really good reason for this. PHP, if you included a file that output any data, such as a blank line, it would start output to the browser. Once output to the browser was started, then methods like 'header()' which set apache headers don't work anymore, they print an error to the screen (yes, readable by the user of the web application, it was configured so that the error was visible to the user).
If you had a PHP file that ended in "?>\n\n" instead of"?>\n", it would screw up any code that set HTTP headers.
It was 2004 before the innovation of omitting the optional ?> tag was introduced into the codebase. When the unnecesery closing tag was removed the issue was mooted.
So to conclude. You could be satisfied that if you opened any file in the codebase, you were guaranteed to be shown a consistent style, methods named in ways you recognise, HTML generated in the same manner everywhere, and you knew that if anyone deviated from this style, then management would pull them up on it.
And that you'd never be faced with anything newfangled like a template.