3 ms·
I don't think this is necessarily true. If I have one place in my code where I sign unsubscribe tokens for emails and another place where I sign cookies for aut
by kevincox 5y ago
I don't think this is necessarily true. If I have one place in my code where I sign unsubscribe tokens for emails and another place where I sign cookies for auth I don't want to implement a HMAC twice. Even if the verification paths are different so the algorithm doesn't actually need to be the same it is still better to use the same code for both so that any bugs, inefficiencies or other problems can be fixed once rather than up to twice.
I think the true decision function lies somewhere in the middle. For relatively simple code that doesn't need to be in sync then yes, duplication is likely the best option. For complex code or code that should stay in sync then extracting the common code is likely best. But there is a huge range of code in the middle where it is a judgement call with no obviously correct answer.
- harpiaharpyja 5y agoYeah, you're right and I think we agree here. I should have been clearer about that.
- kayodelycaon 5y agoEven if you have a number of different hashing functions, each used one, throughout the code, it would make sense to place all of the hashing functions into namespace next to each other. That way you can reuse if needed and checking for security problems is easier. (It can also make the code more readable because the details of the hashing are abstracted behind a method.)
- HelloNurse 5y agoThings that are coincidentially similar are much "larger" and more trivial than something that becomes easier and simpler if it is more abstract like a HMAC algorithm; for example accounting applications would care about records that need VAT and records that reference a counterpart, which are approximately 90% the same and the other 90% special cases with business logic organized according to personal taste.