A blog post by me: wondering that refactoring by extracting functionality into functions is a sign of poor expressivity in programming languages.
The overuse of functions
With the obvious definition of displayUserInList() and removeUserFromList() . But the first approach had certain invariants that the second does not. Assuming you don't mess with the UI/DOM directly, and assuming that updateUserStatus() is called when it needs to be called, the user will be in ...
2 plus ones
Shared publicly•View activity
View 8 previous comments
- I feel like the refactoring in your example is more than just code organization: by encapsulating the behavior for adding and removing users from the list, you're making the statement, "This is how we add and remove users from the list."
Visibility modifiers, on top of that, say, "You are meant to use this to add / remove users" or "You are not meant to use this to add / remove users."
It increases the body of knowledge that has to be learned to modify the software in question, yeah, but as long as human beings are writing the "by hand" then I don't see many alternatives.Jun 11, 2013
- I agree. I'm not advocating template rendering across the board, just noting it is one possibility for refactoring this code. In fact the apps I have worked on, which are in Backbone, we typically go with direct dom manipulation because as you mentioned it does not make sense to throw away large views and re-render large lists just for small changes. I refrained from mentioning Backbone only because the view is changed based on a state change of the "status" attribute (and therefore still needs a conditional check) which is not exactly add/remove on the collection (although I suppose it could be modelled as such).Jun 11, 2013
- Of course my intention wasn't so much to highlight a specific question of UI/domain-logic separation, but to consider a case where an organically created function might be refactored to something computationally equivalent by extracting a chunk of code into a function. Of course since it was an example I kept it short, but tried to use a realistic example. To suggest the frameworkization of the code is... well, yes, some people are drawn in that direction, but I'm more interested in how to avoid that path. But to avoid that path you have to offer another path. I'm not sure what that might be, but I have a hunch that separating organizational concerns from reusable abstractions might be part of it. It's still a pretty vague hunch though.Jun 11, 2013
- One curious language paradigm is Literate Programming, invented by Donald Knuth back in the early 1980s. Though the mixing of documentation and code is the most obvious feature, it does provide a novel way to isolate little chunks of code which can be defined and documented elsewhere, but that all get assembled into the correct place when the code is all weaved together at compile time. I don't think it solves all your issues, but it is certainly a different way of looking at organizing code into little understandable chunks that doesn't involve a function declaration in the typical sense. See <http://en.wikipedia.org/wiki/Literate_programming>Jun 12, 2013
- actionvoipJun 12, 2013
- Finding a good balance seems to be a matter of experience. For application code (i.e. when not designing an API used elsewhere) I usually advocate a rule of threes - only extract repeated code into a function/component/class once it's used three times. But that's really to avoid premature generalisation.
When working on a difficult problem, I often find myself using a functional style in order to postpone solving a part of the problem until later. If it ends up being a short single/dual use function then I'll usually inline it when I make another pass over the code. Comments are a better way of conveying intent than function names and when reading code I want to see what the code actually does, not what the programmer thought it did when they wrote it (often me a couple of months before.)Jun 13, 2013