Personally, I would use the third option because it looks great along with the if statement.
About the first, I think is not an appropriate name: the function's name says that the function will do some kind of modifications to the input email and then, return it.
About the second, I would use it if email were an object:
classEmail{constructor(email){this.email=email;}getuser(){//return text before '@'}getdomain(){//return domain}gettld(){//return top-level-domain}isValid(){//validate email string given in constructor}}
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
isEmail sounds weird because it's too generic. For most purposes you'll be validating a user's input, and if they put in foo@example.com that may be a valid email address but it's not valid for use as such in the context of your app.
If we were building a lexical analyzer, then this could be one way of modeling that. But in this case we are not. Also note: the question is on naming not structure. How naming affects code readability
Naming wise, I like the second one. But if it was purely my choice I would not make a function to name in the first place and have the constructor do the validation during instantiation.
For high level objects that take arbitrary input, like an Email or URL, yes. Other things it's not always necessary because the type system ensures everything else is in order
I like to keep my validation functions in one module, generally named is. So, the call is something like is.email(val). However, if I have to choose a single function, I will name it isEmail. Having valid or validations with is seems a bit redundant to me.
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.
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
if the function is supposed to return a boolean (i.e. false or true), then 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 output
if the function is supposed to throw an exception when the string isn't a valid email address and do nothing if it is a valid email address, then validateEmail seems like the most expressive choice
My thoughts on the other options:
isEmailValid: this one seems more at home in e.g. user.isEmailValid(), so as a plain function this name adds more ambiguity than is necessary
emailIsValid: the same, with the additional concern that it could just as well be the name of a variable/field than a method to be called/queried, so even more unnecessary ambiguity
isEmail: very, very vague. Does this refer to a valid email address, a known email address, an object of the type Email, the route via which the user prefers to be contacted ... ?
My own preference is for is... naming; it makes it clear that it's a boolean. I'd say isEmailValid or isEmail -- but with different contects. isEmail to me implies you are checking whether it's an email at all, but isEmailValid 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.
"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.
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.
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.
Personally, I would use the third option because it looks great along with the if statement.
About the first, I think is not an appropriate name: the function's name says that the function will do some kind of modifications to the input email and then, return it.
About the second, I would use it if email were an object:
Only if you have an email object :-D
Interesting. And what would be the structure of that email object.
I think it will be like this:
For a lexical analyzer or something like that
not meaning to troll or so, but you can have user@ipaddress as a validemail ;)
I say the second,
isEmailValid.Canonical
isprefix when returning a boolean, others could be is-, has-, does.Works well:
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
validateEmailbecause I would expect an error message in return, not a boolean.I would not use
isEmailbecause it sounds weird and unclear to me. I can’t put my finger on why though.I would not use
emailIsValidbecause I assume there would be a series of functions like this, and I would like their names to all start same.isEmailsounds weird because it's too generic. For most purposes you'll be validating a user's input, and if they put infoo@example.comthat may be a valid email address but it's not valid for use as such in the context of your app.isValidEmailadded. Thanks for the feedback.Functionally, I like the second one the best.
I also concur with the
However, to go with the object-oriented I'd prefer
If we were building a lexical analyzer, then this could be one way of modeling that. But in this case we are not. Also note: the question is on naming not structure. How naming affects code readability
Naming wise, I like the second one. But if it was purely my choice I would not make a function to name in the first place and have the constructor do the validation during instantiation.
Does this mean that you will have to create a class and do validation in the constructor for everything in your code that needs validation?
For high level objects that take arbitrary input, like an Email or URL, yes. Other things it's not always necessary because the type system ensures everything else is in order
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. Havingvalidorvalidationswithisseems a bit redundant to me.Nice catch. Let me also add that as a possibility
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.
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
isEmailwill create confusion, and it will have to refactored toisEmailValid.As with most things, it depends:
isValidEmailseems 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 outputvalidateEmailseems like the most expressive choiceMy thoughts on the other options:
user.isEmailValid(), so as a plain function this name adds more ambiguity than is necessaryMy own preference is for
is...naming; it makes it clear that it's a boolean. I'd sayisEmailValidorisEmail-- but with different contects.isEmailto me implies you are checking whether it's an email at all, butisEmailValidis 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.
"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
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.
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
I prefer number 2 because it is specific to the context of returning true or false.
Number 1 isn't bad but it's more appropriate for doing more steps of validating the email other than true or false.
What about number 3?
emailIsValid seems to assume the email is already valid.
I try to be more specific when I write; keep the structure close to english or native language to avoid cognitive overload.
Acronyms are my preference: "iev"
ievis not clear at all. How would the next person maintaining your code whatievmeans?