Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Based on this question. Would you consider it best practice to create a function that does the opposite of an existing function just to give it a different name.
Example: If you already have bool In(string input,string[] set) which returns true if the the array set contains the string input and false otherwise, should you create a function like bool NotIn(string input,string[] set) which returns false if the string is in the set or true otherwise?
No, certainly not best practice at all. All languages that I've ever used have a "not" operator, so use that. It's very clear, very easy to read and it saves writing essentially duplicate methods.
E.g. the meaning and the intention of the code below seems to me to be pretty clear:
if (!In(...))
{...}
Whilst if I saw a bit of code like this:
if (NotIn(...))
{...}
I'd think, "this is probably the opposite of In(), but if it was why didn't they just write !In()". So, I'd end up having to check the docs or the code :(
Obviousy it is not syntacticaly wrong to write such a method, it's just not idiomatic (in any langauage I''ve ever used).
Edit As Amir mentions on the comments, this is the kind of thing that might well be covered in coding standards, along with how to name a method (or property) that returns a boolean value.
In functional languages, this is may be sometimes convenient for predicates that are passed to other functions, i.e.
filter (`notElem` xs) ys
looks nicer than
filter ((!) . (`elem` xs)) ys
This Haskell example demonstrates that the syntax rules may force one to write 4 extra parentheses just for a simple negation. Because clarity diminishes overproportional to the number of parentheses, it is good to have notElem.
As long as they are mutually exclusive you shouldn't. You should however do it, if you'd have 3-valued logic (True, False, unknown). Which happens to be typical for example in SQL.
(source: wikimedia.org)
In() returns a tri-state then !In() may not be the same as NotIn(). If it is some sort of cached collection, which tells you unknown so that you can chose whether to perform some expensive lookup, then it might know when things are definitely not present, but not know when they definitely are, or some other asymmetry.
Apr 15, 2011 at 22:54
IsWritable and IsImmutable might behave as opposites for present versions of a class, but future classes might reasonably return false for both (e.g. if the object represents a read-only view of mutable data which is owned by some other object that could change it). While the combination of properties would have three states, each would have a well-defined Boolean value.
No, you definitely shouldn't. A negation operator is sufficient.
However you may want to think first what is the most "popular" use of this function - to ask for a direct answer or for a negated one. Then you do the most used check by default.
For instance, if you have a method Question.IsOpen() and you observe that you're mostly calling it along with the negation like !Question.IsOpen() you could reverse it into Question.IsClosed(). Here you notice how it is quite possible to find a separate word for a negated situation.
IsOpen and IsClosed may often be a good idea, if there's any possibility that an object might be in a state where it is not presently usable, but is also not ready to be abandoned, especially if there may be significant time between when an object is asked to open and when it becomes ready for use.
If I have a property that I'm binding to in say an mvvm project in WPF, then I create explicit versions of properties that are the direct opposite of others. Though, I prefer to use fairly detailed symbols of what the meaning is rather than just prepending 'Not' in front of the opposing property name. I guess if you're talking functions and pure code I'd probably agree that you should use proper not operators instead.
I would say it depends. Ruby, for instance, encourages this due to readability/clarity > all else. It's common practice in a Rails app to wrap up the negation operator in a method to make the code more English-like if it doesn't "flow" naturally using the unless keyword.
unless in_set (which is a bad example because that does sound right) you would make a not_in_set function so you could write if not_in_set instead. It depends on the specific context; I was merely stating the Ruby convention is to use these reverse boolean functions when it would help readability/express intent.
Apr 19, 2011 at 14:51
I agree with others here that suggested the use of the not operator, when you are using existing libraries.
When you are writing your own functions, I would name them such that callers can author their conditional with positive semantic. For example, allow them to write if(lightIsOn) by naming your function lightIsOn(...).
!someBoolmeans at a glance then, well... they have a serious problem.isNotValid()intoisValid()is a good thing to do, but the other way around it's not.