A contractor has little choice but to live with the coding standard imposed by the client company. The result is I've worked with most of them, except Hungarian.
You claim that Hungarian and other type prefixing standards exist to make up for bad coding practices. I claim it's because the software IDEs are so bad. There is typically no easy way to get a type definition for a variable given the scope it's in. Under UNIX you can easily write/run a small program that will show you the current type definition for the variable, where it's defined and if it hides another variable.
Encoding the type as a prefix is just as bad as adding a comment like /* increments i by one */. It's redundant, will be wrong some percentage of the time and adds noise.
Long variable names do the same thing. They often mislead the reader as to what the code really does with the variable. Debugging a program with long descriptive variables is much harder in my experience. Especially when the name describes the original intention and not the actual practice.
Standard naming conventions (caps, underscore) are important purely for communication with colleagues.
Indentation standards help to reduce the size of diffs between versions of the same program when multiple people have to cooperate together.
Portability should just be a matter of agreeing what interfaces will be available on all platforms and making sure the use of any other platform-specific API is well isolated in the code.
The rest should be left to the individual programmer to make their code as readable and understandable as possible.
Use good programming tools to aid in the development and understanding of a body of code, don't obfuscate the code to make up for a lack of good tools.