Don't Repeat Yourself
Information
The DRY principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". This goes for anything:
- Business Logic,
- Documentation,
- Build scripts,
- Database schema,
- Tests.
Sometimes 2 pieces of knowledge have the same representation, its just a coincidence, don't combine them into one if you see "the same" code in 2 places.
This principle comes from the The Pragmatic Programmer.
Example
Two pieces of knowledge
When you have 2 pieces of knowledge for example a username and a post title validations, and they both have the same implementation, but they are not related, don't combine them into one.
Username:
func validateUsername(username string) error {
if len(username) < 3 || len(username) > 20 {
return errors.New("username must be ...")
}
if !alphanumericRegex.MatchString(username) {
return errors.New("username must only ...")
}
return nil
}
Post title:
func validatePostTitle(postTitle string) error {
if len(postTitle) < 3 || len(postTitle) > 20 {
return errors.New("post title must be ...")
}
if !aplhanumericRegex.MatchString(postTitle) {
return errors.New("post title must only ...")
}
return nil
}
If you would combine them and later you business rules change, you would have to split them back again or add logic to the function which would make it less readable.
Breaking DRY principle
// ValidateUsername checks if username length
// is between 3 and 20 characters and if it
// contains only alphanumeric characters
func ValidateUsername(username string) error {
if len(username) < 3 || len(username) > 20 {
return errors.New("username must be ...")
}
if !alphanumericRegex.MatchString(username) {
return errors.New("username must only ...")
}
return nil
}
Here we repeat the same piece of knowledge, comment and code both describe user validation. Here its easy to update code if Business Logic needs updating, and forget about updating the comment. Imagine later on someone reads the comment and doesn't read the code...