Standards on the client-side help accessibility (since you never can be certain what will and won't be available to the user within the user's own browser and computer).
Server-side scripts written in cross-platform languages like PHP generate the same code for all end-users regardless of their platform (except in the case of bad form submission or other likewise annoying client-side limitations).
Therefore the only needs I can see for producing PHP according to some specific coding standards are the following: 1. Code portability. If, for instance, you rely on some obscure PHP.ini settings to be set, you cannot redistribute your webapp onto different server environments. 2. Code collaboration. If you have multiple people coding one backend (as is often the case), having a unified standard for coding is essential.
The phrase 'coding standards' is used here in a very different context to W3C standards. Coding standards are optional. Server-side scripts are compiled; they do not accept variation or quirks like a web-browser must.
To draw frontend parallels, you can't leave 'tags' open (if you consider a function declaration a 'tag'), you can't omit quotation marks (or else you get a parse error), etc., etc.
Of course, there are best practices to be followed. MVC for instance.
True. But surely, to have a standard code, even a script developed on a language that we already have, would stop all problems, server-side. Human error is what causes these problems, and that error is caused, in effect, by lack of certanty. To have a definate guide to show what's right and what's wrong would rule out all mistakes. This, in effect is the basis of all programming. Right and Wrong.
But if your compiler throws a fatal error when you screw up, there's really no requirement for validation against a standard: if you don't follow the language constructs, your site won't work.
The issue with the web was that so many designers would design in IE, test in IE and deploy. Needless to say, that left the web somewhat disheveled. When you test server-side code in one browser, you're testing the server, not the client, and so while the server remains the same, there's no standard needed to be conformed to.
You can't do 'what's wrong' in PHP. Not unless you count warnings/notices as 'wrong' (which I do), and you've got errors turned off (which you shouldn't while testing).
Well I disagree that standards are not necessary on the server side. Just because a compiler catches syntax errors or 'what's wrong' in your code doesn't make it good code.
That being said, there are standards at different levels that may or may not make sense depending on how large an audience for your code will be. If you have plans on making your code an open source project at some time in the future you may want to start out with coding standards. This means decide how you want to name variables camelBack or under_scored to issues such as tabs vs. spaces for indenting. I always do this for myself because it makes scanning my code dramatically easier. Having worked on large projects where everyone had a different coding style, it became a nightmare just to look at the code.
You also want to decide which languages, platforms you want to work with. For most web sites there seem to be two main platforms Linux/BSD unix or Microsoft. Next you need to choose your language - PHP, Python, Ruby, or ASP (Java seems to be used mainly on intranet applications or dedicated machines - i.e. large applications). Then your database - MySQL, PostreSQL, or SQLServer. The two most popular configurations seem to be Linux-Apache-MySQL-PHP (LAMP) or Windows-IIS-SQLServer-ASP.
Next you want to think about good coding structure and at what level of granularity your classes should be (talking PHP and Java here - not familiar with ASP). A good rule of thumb is to code for reusability. If breaking a class into smaller classes will let you reuse the smaller classes over and over again, then it is probably worth the effort. I would also visit different design patterns to help deciding on how to code classes so that they can be reused easily. MVC is an early design pattern and is a good start. Of course use common sense here. Remembering a ton of small classes and what they do can be an even bigger headache than having a moderate amount of redundant code. There are some documenting tools that can generate class documentation providing you code your function comments a certain way (javadoc for Java, and phpdoc for PHP).
Finally (if you have time and strength of will) you can standardize your testing. I like to use a test suite. This requires creating a tool that can emulate a browser (or just an HTTP request) to send a request to you server side code and accept a response and comparing that response or part of it to an expected result. This is not as hard as it sounds and you could run the test suite on the server itself. Figure out what your browser sends to the browser for certain or alternatively call the functions directly. capture the correct output and save that as your baseline. Future tests will compare what is returned against the base line or a portion of it. When you find and fix a bug, add this to your test suite so the bug won't magically reappear in the future. Tests suites make sense if you have a large complicated system that you make changes to often.
There's another issue; I think there is a case for a standard for backend data. Front-end standards are all about accessibility across human factors and devices: same data - different, equally accessible ways to consume it.
But there's also a benefit if data is transportable between platforms.
I've been involved in such an effort over in the Port 80 forums: " Common CMS Export Protocol' http://forums.port80.asn.au/showthread.php?t=10473
Basically, the aim is to ensure clients are not locked into one vendor's CMS platform and can take their site data with them if they change CMSs. There are a lot of custom CMSs out there.
If you are concerned about this you might want to consider doing your markup in xml/xslt, then defining the xslt transformations in a way that is w3c compliant / accessible. Provided you make a system wide link to your xslt document you should be able to control all dat in a standard way. Otherwise you could use standard expressions to rewrite invalid code using a server side language.
Also, it is very possible to write a standards compliant program in a variety of server side languages, but this will be reflected in the html it returns to the browser. In terms of the server side code being valid, there are typically strict programming standards for these languages (alot more strict than html) and the programs will simply not run if you run an error, or for instance run slowly if you use redundant, non-class based programming where necessary.