Between these functions which one do you feel is appropriately named?
For further actions, you may consider blocking this person and/or reporting abuse
Between these functions which one do you feel is appropriately named?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (29)
"If am I developer?". Your code is a set of commands and statements. It doesn't ask its reader questions like how their day is. And everything, that's not some Email class's own function (a'la email.isValid) and that starts with "is" sounds like a question.
Only emailIsValid(email), rain or shine.
Also constructions like "if email is email" make no sense. Of course it is. You need to have a quality (such as "valid") to be used to distinguish good emails from bad ones.
Cheers
prereq question: Is 'email' an actual email or is it an email address?
Calling an 'email address' 'an email' could lead to confusion when you get to actually sending emails.
I'd prefer
function isValidEmailAddress(str)
You also probably shouldn't be checking if their email address is valid. Just send the email.
hackernoon.com/the-100-correct-way...
I think this is the only valid answer so far. ;)
Seriously though, all the rest ignore the fact that validation is being performed on an email address, not an email. The order of the words doesn't matter much if they're misleading words.
And yup, even an email address with a valid format can still be wrong. I get spam all the time because people keep mistyping their email address. It drives me nuts.
So if you do anything at all, send an activation email.
isEmail is the best approach :) :)
verb + keyword
isValidEmail is redundant. Imagine the following scenario: A string can be a email, but invalid, so, if is invalid, is not an email. So "isEmail" is very good naming.
github.com/typestack/class-validator
As with most things, it depends:
isValidEmail
seems like the most expressive, in that it leaves the least room for doubt regarding what the method requires as input and what it will return as outputvalidateEmail
seems like the most expressive choiceMy thoughts on the other options:
user.isEmailValid()
, so as a plain function this name adds more ambiguity than is necessaryAcronyms are my preference: "iev"
iev
is not clear at all. How would the next person maintaining your code whatiev
means?My own preference is for
is...
naming; it makes it clear that it's a boolean. I'd sayisEmailValid
orisEmail
-- but with different contects.isEmail
to me implies you are checking whether it's an email at all, butisEmailValid
is checking if it is a valid email. A valid email is certainly an email.Honestly, I'd probably have both, for different purposes. They read as completely distinct.
Usually isEmailValid cause it‘s a common convention for functions/methods that return Boolean, and thus will behave predictably for readers.
For the requirements as code project, I would use emailIsValid, as this is the closest you can get to speaking (when email is valid, do this). And I use that to generate documentation from the code.
So there are sometimes reasons to break from the norm.
It returns a boolean answer, so the function should be a question, so it should start with "is" in this case.
I don't think there is a case where "isEmail" and "isEmailValid" are 2 different things, so I will choose the simplest one #KISS.
but ...if you have more features like
isEmail
will create confusion, and it will have to refactored toisEmailValid
.Not listed, but I would use
isValidEmail
.is*
is a good way to indicate true/false return value. Andif (isValidEmail)
reads well.I would not use
validateEmail
because I would expect an error message in return, not a boolean.I would not use
isEmail
because it sounds weird and unclear to me. I can’t put my finger on why though.I would not use
emailIsValid
because I assume there would be a series of functions like this, and I would like their names to all start same.isValidEmail
added. Thanks for the feedback.isEmail
sounds weird because it's too generic. For most purposes you'll be validating a user's input, and if they put infoo@example.com
that may be a valid email address but it's not valid for use as such in the context of your app.I like to keep my validation functions in one module, generally named
is
. So, the call is something likeis.email(val)
. However, if I have to choose a single function, I will name itisEmail
. Havingvalid
orvalidations
withis
seems a bit redundant to me.Nice catch. Let me also add that as a possibility