We have a large project written in PHP. It almost exclusively uses imperative operations, as in example 1. Should we refactor our existing code to use functional operations? Do you think that the code in example 2 is easier to maintain?
Example 1 – imperative
$cookieString = '';
foreach($cookieArray as $cookieName => $cookieValue) {
if($cookieString != '') {
$cookieString .= '; ';
}
$cookieString .= $cookieName.'='.$cookieValue;
}
return $cookieString;
Example 2 – functional
return KeyedStream::of($cookieArray)
->mapEntriesToStream(function($cookieName, $cookieValue) {
return $cookieName.'='.$cookieValue;
})
->joinToString('; ');
}
1
Ask yourself honestly why you want to refactor. That’s really important. then think what you’re doing at your company – are you hired to write nice code, or to create good product.
I think too many developers get so caught up in the minutiae of the codebase that they forget what they’re supposed to be doing – which is making something useful out of it. Its like a bricklayer worrying if he should change the clay mixture in his bricks when he’s building a wall! (no brickie does that – they build the wall, then go and build more walls. Walls are important, the bricks only so as they make walls happen)
So question what your true motive is here. Is your code so difficult to understand that changing things is too costly? Is your code so rubbish that you cannot understand it to change anything? If the answer is no, then spend your efforts doing something useful.
I admit, I love refactoring code – but chose wisely what to refactor and why.
Will the user of your code clearly benefit from the rewritten code? Will the user demand this new functional style code, or is it just a developer thing, to try coding with a different style? If there is no benefit for the user at all, except the code is now looking “nice”, who is going to need it? You are replacing one fashion by another. And this is YAGNI – You Ain’t Gonna Need It.
If the code basis is large, it means also this code is already developed over years, which means that the current code basis is already full of different code styles. And if we are talking about a large code basis, it sounds to me that you might have a lot of legacy PHP code too. You should be aware that refactoring/rewriting code will very probable introduce new errors. Every user hates new errors when the former code was working.
Are you prepared to fight the introduction for new errors? I mean, do you already have unit tests to detect errors or regressions? If you do not have unit tests, how will you be certain, that you understood the code you going to transformed into a functional style expression? Write unit tests! If this code is not testable – make it testable. As long as there are no unit tests for the fragments you want to refactor – do not refactor.
Refactoring is a lot less error-prone if your IDE supports factorings. Even then factorings aren’t trivial and will often result in new unseen behavior.
- Refactoring Java code: excellent IDE-Support (Eclipse, IntelliJ, Netbeans, … )): just commit often (every ont to two minutes), while refactoring. Most refactorings are pressing some key-combinations.
- Refactoring PHP code: I experienced bad IDE-Support: this means lots of manual steps, where each one could introduce new errors.
I do boy-scout-rule changes, whenever I touch some code nearby, I sometimes extract a method, rename a method, introduce a parameter instead of using a field in the class, change method signature, rename a field, … But i never try to fix something I come across, what just looks wrong. If it is wrong, why does nobody complained about it, and when nobody complained, what may I missed? Write a test / tests for wrong looking code.
I do refactorings e.g. from GUI-god-class-code to patterns, if and only if, I must fix an error in this class and/or add a new functionality for that class. This is usually for code I inherited from other developers.
Could you maybe use the time you might spend on refactoring this code better used for something of more benefit to the user? Some of these benefits are also unit tests and continous integration.
If you like this functional style use it for the new code. But I find example 2 not any more readable than provided code in example 1.
hth