My mine problem with Clean Code is Uncle Bob technique for refactoring big functions into classes. When you have a long pure function that has several local va

My mine problem with Clean Code is Uncle Bob technique for refactoring big functions into classes. When you have a long pure function that has several local variables and changes them in several places - you can't trivially split it into smaller pure functions (because you would need to return several values from each of them). You could return Pair<X,Y> or similar, but that's clumsy in Java. Sometimes these values form a single consistent type - then it's simple - make a class out of them and return that. But often they don't, they are just conceptually independent parts of the algorithm. For me that just means the function is cohesive, either change the algorithm or keep away. Uncle Bob's advise is to make a new class out of that function, change the local variables into private fields and split the code into methods of that class with side effects modifying these variables all over the place. This results in exactly the kind of code this article complains about, and I agree it's awful. We managed to change code that was explicit about what it does, with no side-effects and no easy way to break it accidentally - into a mess of small interlocking surprises. Whole classes of programming errors that were basically impossible previously are now easy to make. Can this state even happen when I'm in this function? Should I check for it? Can I call this function after I called that other function? Can I change this variable in this function after requirements changed? The answer after the refactoring is "Dunno - solve this intricate puzzle to find out."