There's nothing preventing your or any other company from writing their own coding guidelines and ensuring their code follows them by the means of code reviews.

Hear! Hear! I have maintained code in VB, Java, C# (a little), Perl, Pascal, COBOL, and RPG/400. Of those, VB, Java, and C# supposedly have "standards" that enforce maintainability of the code; and that's a damn lie -- or rather, that's marketing (which is worse).

Maintainable code is only ever quasi-guaranteed, but the only way I've ever seen it is when the dev team -- with the support and backing of management -- creates and enforces code style guidelines. The only time I've ever seen this done well is in a Perl shop.

This shop was a dream: code was checked into version-control via scripts which first ran PerlTidy with the corporate-standard options (and you could spec your own pass to your favorite style on checkout, but almost no-one did). Any style guideline that could be enforced by PerlTidy, was. The rest were handled by two-tier code review; we had peer-review which checked for style as well as good methodology and all the other peer-reviewy type stuff, and the repository maintainer reviewed solely for style-rules that weren't PerlTidy-enforceable (like "modules can be either OO or functional/procedural, but not both" and "subs that act on on non-scalar data must accept the appropriate reference (e.g. arrayrefs in place of arrays)").

I have never seen that level of commitment from any shop, and I have never seen an automated tidying-tool that worked as cleanly in automation as PerlTidy.