Hello there, my sweet fellow developers,
Today, I’m going to talk about the thing, that troubles me a lot. You see, I’m a CTO of a software development company. Moreover, I’m a friend to multiple other software development companies and startups, whom I help to establish the mobile coding culture or just interview people. Because of that, I have an extensive experience in reviewing the code of others. I do that while interviewing, performance-reviewing, code reviewing for lulz and/or profit.
And you know what? I have a butthurt because of simple mistakes people tend to make. So, in this series of articles, I’ll show you different ways of improving your code and making it more extensible and readable. And yes, I’ll rant and whine from time to time.
At first, I’ll give general recommendations:
- DRY (don’t repeat yourself);
- Learn the instruments you are using;
- Reflect on your code;
- Extend your outlook to improve your code.
The second recommendation is actually the specialization of the first one. You see, you will duplicate the code, if you don’t know the language or frameworks you are using. I can confess, that I reflect on my code at least 4 times a year and each time I find something, that results in an average of 100 WTF per minute. Then, I accept my fate as an incompetent fool. Then, I search for a better solution and then I try to avoid such mistakes.
By extending the outlook I mean learning new languages and paradigms. Recently, I started learning FP and I can tell you, that I will never code the way I previously did afterwards. Same happened, when I tried Ruby, when still writing in ObjC. Overall, the more you try, the better you code would be. As Paul Graham once told, you will never be able to write lisp-like code in other languages, but your code would definitely become better even in more limited languages, if you know lisp.
The first recommendation is the king, as duplication results in a bad reusability and extensibility, which in turn results in a lot of error-prone code, which consumes the programmers time, like a fat and hairy wild undead misanthropic hog filled with fury towards the living. It’s really hard to modify such a code. Lets just take a look at the following code:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
func badPrintPrefix() { print("prefix") } func badAppendPrefix(toString string: String) -> String { return "prefix" + string } func badAppendPostfix(toString string: String) -> String { return string + "prefix" } |
The code is pretty simple here, but it would be a pain to change the code, if we want to change the “prefix” string into “mama” for prefix functions, but leave “prefix” untouched for postfix functions. The solution in here is pretty simple. Never use constants of any type (be it a string, number, object or anything else) hardcoded in the code. Put them in lexically scoped constants with clear names. The code above could be rewritten as following to use such a recommendation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
struct Keys { static let prefix = "prefix" static let postfix = "prefix" } func printPrefix() { print(Keys.prefix) } func appendPrefix(toString string: String) -> String { return Keys.prefix + string } func appendPostfix(toString string: String) -> String { return string + Keys.postfix } |
Any changes related to something specific are done in one place, which is the ultimate goal of deduplication and DRY.
That’s all, folks. Have a great day and stay DRY, no matter, where you are.
(1 votes, average: 5.00 out of 5)
Loading...