Theoretically, prepending salt (non-secret data) to password (secret data) is bad. Because, since hash functions process their input sequentially (in blocks of 1 to 64 bytes and more), it is possible to precompute hash function state for the initial blocks of non-secret data and use it as a starting point for all future permutations, — effectively removing almost any additional protection a salt may introduce. However, practically, salt + password usually occupy less than a single input block of a cryptographic hash function (typically, 512 bits or more), so this is not considered an issue.
More important thing is that, when it comes to cryptography, you should never invent your own wheel, but rather use an already existing security scheme whenever possible. When you ask yourself: “Should I do this, or should I do that?” (like “Should I prepend or append salt?”) — chances are high that you are inventing a wheel, which will give you a false sense of security.
With the task of “salting a password”, one road to take is the Hash-based message authentication code (HMAC) scheme, also known as keyed hash: simply use your salt as message and your password as key — and the function will combine the arguments in a proper way, relieving you of duty to remember “whether to prepend or append”. This function is actually a wrapper for regular hashing functions and is quite simple, so you may easily implement it yourself if your crypto framework lacks one, but be sure to test against known results.
The other possible alternative is a Password-Based Key Derivation Function like PBKDF2, which is yet another wrapper on HMAC or similar function. An important benefit of PBKDF2 is that it may perform several [thousand] rounds of hashing instead of just one, which may be increased as processing power evolve.
PS. You do understand that salt must be chosen random on each occasion and not remain static (or, even worse, a dictionary word), do you?
