-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
d9f22a2
commit 50b79d3
Showing
1 changed file
with
21 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,24 @@ | ||
# validator-go | ||
|
||
A simple and extensible validation library for Go. | ||
|
||
|
||
## Design Choices | ||
|
||
### No Default Email Validation Checker | ||
|
||
In developing this library, a conscious decision was made not to include a default email validation checker. This decision was informed by several key considerations, outlined below. | ||
|
||
#### Overly Restrictive Patterns | ||
A common issue with email validation is the use of overly restrictive regex patterns. These patterns can inadvertently reject valid email addresses, causing false negatives. This is particularly problematic given the wide range of valid email formats permitted under RFC standards. By not imposing a default pattern, we avoid the risk of excluding valid emails due to overly stringent criteria. | ||
|
||
#### Incomplete Validation | ||
Many basic regex patterns are limited to verifying the format of an email address. They do not, and indeed cannot, confirm the actual existence or validity of the email address itself. This superficial validation often leads to a false sense of accuracy, overlooking the fact that a syntactically correct email address might still be invalid in practical terms. | ||
|
||
#### Complexity | ||
Designing a comprehensive regex pattern for email validation that covers all possible valid cases is surprisingly complex. The challenge lies in accommodating the vast array of valid formats while effectively screening out invalid ones. Striking this balance is difficult and often leads to a pattern that is either too permissive or too restrictive. | ||
|
||
#### Customization for Specific Use Cases | ||
Recognizing that different applications may have unique requirements for email validation, our approach prioritizes flexibility. By not providing a default validator, we empower users to implement a regex pattern that is tailored to their specific context and needs. This decision aligns with our commitment to providing versatile, adaptable tools that serve a broad range of use cases. | ||
|
||
In summary, we encourage users to leverage the regex validation function provided in our library to create custom email validators. This approach allows for greater precision and adaptability, ensuring that the validator aligns with the specific requirements and constraints of your application. |