Hard coding is fine. For a short period of time
TL;DR: Don't leave a hardcoded mess on IFs.
Problems
Testability
Hardcoded values
Open/Closed Principle Violation
Solutions
- Replace all IFs with a dynamic condition or polymorphism.
Context
Hard-coding iF conditions is great when doing Test-Driven Development.
We need to clean up stuff.
Sample Code
Wrong
private string FindCountryName (string internetCode)
{
if (internetCode == "de")
return "Germany";
else if(internetCode == "fr")
return "France";
else if(internetCode == "ar")
return "Argentina";
//lots of elses
else
return "Suffix not Valid";
}
Right
private string[] country_names = {"Germany", "France", "Argentina"} //lots more
private string[] Internet_code_suffixes= {"de", "fr", "ar" } //more
private Dictionary<string, string> Internet_codes = new Dictionary<string, string>();
//There are more efficient ways for collection iteration
//This pseudocode is for illustration
int currentIndex = 0;
foreach (var suffix in Internet_code_suffixes) {
Internet_codes.Add(suffix, Internet_codes[currentIndex]);
currentIndex++;
}
private string FindCountryName(string internetCode) {
return Internet_codes[internetCode];
}
Detection
[X] Automatic
By checking If/else conditions we can detect hard-coded conditions.
Tags
- IFs
Conclusion
In the past, hard-coding was not an option.
With modern methodologies, we learn by hard-coding, and then, we generalize and refactor our solutions.
Relations
More Info
Credits
Photo by Jessica Johnston on Unsplash
Don't be (too) clever. My point was to discourage overly clever code because "clever code" is hard to write, easy to get wrong, harder to maintain, and often no faster than simpler alternatives because it can be hard to optimize.
Bjarne Stroustrup
This article is part of the CodeSmell Series.
Top comments (0)