I have one one software system which allows developers to specify an ID or name to create NodeReferences
. Both work fine, but ID's are not guaranteed to be the same across different environments. I've tried in documentation and in conversations to stress that ID's should not be hard coded (since they will break when deployed to a different environments), but some developers are still using them.
This works only in dev environment:
var level = LevelReference.ById(20);
var node = NodeReference.ByName(level, _patientGuid.ToString());
This works in all environments:
var app = ApplicationReference.ByName("Reporting");
var area = AreaReference.ByName(app, "Default");
var level = LevelReference.ByName(area, "Patient");
var node = NodeReference.ByName(level, _patientGuid.ToString());
I think the appeal is just that it produces fewer lines of code. The use of ID's is not by itself bad (since there are valid use cases like caching the ID returned from the server and using it later for faster look-up), but hard-coded ID's are bad. Most of the time the first code will throw an exception, but it's possible that it could be a valid ID for a different object than the developer intended, and this could result in very bad problems.
What's the best way to discourage the use of such constants in code? Ideally I'd like throw some kind of compiler error when I see code like the first example, or at least throw an exception before the call gets down to the database.
grep
, so you might be able to get a leg up on your code base that way.ById(int)
would be a magic number. Not getting rid of magic numbers is a bigger issue than just passing them into this method.