In a few implementations of hashed passwords, I have seen that the length of the random salt is chosen to be, say, 10 or "some constant". Is there any specific reason why the salt is chosen to have a fixed length? Can a smart attacker take advantage of it?
Does hashing a password with a random salt make the password stronger?
Well, the reason we add salt when hashing passwords is not to make a single hashed password stronger (it doesn't, except in a way I'll explain below), it's to fix up some weaknesses that appear when you have a collection of hashed passwords.
If the attacker somehow gets a single hashed password, then adding a salt doesn't really slow the attacker down (assuming that he gets the salt as well; since the salt is commonly stored with the hashed password, this is a reasonable assumption). Without the salt, the attacker can guess various passwords, hash them, and see if any of them hashes to the target value. With the salt, the attacker simply includes that when he hashes his guesses, and so that doesn't make his job any harder.
However, if the attacker gets a list of hashed passwords, then adding a salt does make the attacker's job harder. Without the salt, the attacker can guess various passwords, hash them, and see if any of them hashes to a value on the list; if he has a collection of 1000 hashed passwords, he has just checked 1000 passwords with a single hash. On the other hand, if each hashed password includes a salt, and if each salt is different, then to check to see if a guessed password is accurate, he has to run 1000 hashes (with each hash using a different salt); this does make his job harder.
In addition, there are clever ways that an attacker can use to precompute hashes of various possible passwords (and store those in a manner that is considerably more compact than the list of hashed passwords). Without salt, the attacker who has spent the time to create the table can quickly check if any of the hash passwords happen to be one of the ones he has precomputed. It turns out salt interferes with those as well (because the salt is another thing that the precompute method would need to guess, and if the salt is of reasonable size, this is impractical).
Now, when I mentioned above that there is a way that a salt makes even a single password stronger, it's because of these precomputation methods. It makes the use of a precomputed table impractical. The attacker can still do a dictionary search on the hashed password, but he has to do the computation after he has obtained the hashed password (and he can't reuse that effort to attack anything else).
Finally, the other thing that salt helps with is to obscure whether two passwords happen to be the same. Without salt, two identical passwords will hash to the same exact value, which an attacker that gets the hashed values can see. Even if the attacker can't tell what the common password is, it may give him information that we don't want him to have (such as "User X" and "User Y" are the same physical person). With salt, there is no such information leakage.
You also asked about salt length; from the above discussion, it should be obvious that we want salt values to be unique. One easy way to make them unique is to choose them randomly, and make them long enough that collisions (that is, two passwords get the same salt) are unlikely. In general, if we can expect to have $N$ different hashed passwords, we'll want at least $N^2$ different salt values (with more being better); 10 random alphanumeric characters does this nicely. As for always picking the same salt length, well, since we assume that the attacker can see the salt values, we don't want the salt lengths to leak any information about the password. Choosing the same length for all salts achieves this nicely.
The role of the salt is to be as unique as possible: two distinct instances of a stored password (for two distinct users, or two successive passwords for the same user) shall use distinct salt values. Preferably, this uniqueness should be worldwide: it is best if there is no salt collision even across two installations of the same software (or different softwares using the same password hashing algorithm).
The penalty for a salt collision is that the two passwords which use the same salt value could be attacked for the same price as attacking one password. Here, I am talking about dictionary attacks: trying potential passwords until a match is found. The smart attacker will try to attack several passwords simultaneously, or use precomputed tables, to lower the attack average cost; salt uniqueness prevents that.
Worldwide uniqueness is hard to guarantee, but with random salts (with a good PRNG) of sufficient length, the risks of collision can be made arbitrary low. With 10-byte salts, risks of having even one collision are negligible until billions of passwords are stored.
Apart from uniqueness, salts have no constraint, and trigger no security issue by their length or structure. Note that salts are not secret (if they were, we would call them keys, not salts): a salt is normally stored along the hashed password, and it is assumed that the attacker knows it.
