3 added 197 characters in body
source | link

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.

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)

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.

2 added 488 characters in body; edited body
source | link

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)

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.

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)

1
source | link

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.