7 ms·
I read the same thing in "Clean Code" (amazon: http://is.gd/mJ8g http://is.gd/mJ8g ) I have two objections: First, what is "one thing"? Render a Doom 3 frame?
by mdemare 18y ago
I read the same thing in "Clean Code" (amazon: http://is.gd/mJ8g http://is.gd/mJ8g )
I have two objections: First, what is "one thing"? Render a Doom 3 frame? Or increment the "i" variable? The "Clean Code" author argued that a log statement or a try/catch statement deserved its own method.
Second: says who? Where's the evidence that doing "one thing" is better than doing more things?
In general I notice that there are many rules and best practices in programming, without a lot of evidence, or even discussion of the drawbacks.
- llimllib 18y ago> First, what is "one thing"? You're the author, dude! What you choose as the "one thing" of any given method gives me, the reader, information. You can emphasize an activity by breaking it out into a method, or de-emphasize it by leaving it inline. There's no evidence that Poe was a great short story writer either. You have communicative power with your choices; use it consistently and wisely.
- DenisM 18y agoTo answer your first question, the right size of the method is that which a typcial maintainer of the code has no problems holding within his head. The "one thing" is a one-statement decription of the method such that the maintaner does not need to look inside the second go around undersand the place where it is being invoked. As to your second question, I have no answer. It is a bunch of voodoo right now and I have to wonder which body could, even in theory, produce a scientificaly valid proof of efficiency (or lack thereof)?
- huherto 18y agoYou break complex tasks in simpler tasks: - Go To School - Shower - Get wet - Clean - Rinse - Get Dressed. - Have breakfast - Prepare food - Eat So different tasks have a different level of detail. The advantage is that you end up with more reusable methods. Like "shower" or "Prepare food" that can be used elseware. In another time there used to be more emphasis on top-down design, but I feel that has been lost and I do not know if it is still taught.
- jonnytran 18y ago> The advantage is that you end up with more reusable methods. Like "shower" or "Prepare food" that can be used elseware. But that is exactly the author of this post's point. When you have something that is more reusable, like "Prepare food", you end up using it in multiple situations, increasing the complexity of relationships between components. So for example, when you want to make sure you eat bacon with breakfast, you can't just add "Prepare bacon" to "Prepare food" b/c now the "Prepare food" task may be executed in "Have lunch", "Have dinner", and "Have midnight snack". And you don't want bacon with your midnight snack! Instead, you have to add a parameter to the task, some conditional, add parameter to each call site, etc... i.e. more complex.
- xenophanes 18y agoRe-using showering code is less error prone than maintaining separate copies of showering code!
- pdubroy 18y agoNot necessarily. When you make a single change to a shared function, you might cause undesired changes to other code that calls that function.
- xenophanes 18y agoSo you're advocating copy/paste style coding, and telling us it is less buggy? Seriously? And without some extensive explanation? What about the studies showing number of bugs is proportional to lines of code? Your way adds more lines of code.
- pdubroy 18y agoNo, I'm saying that putting common code in a separate method is not necessarily -- as in, "as a logical result or consequence" -- less error-prone. I'm not advocating cutting and pasting huge blocks of code everywhere, but a 1-line calculation duplicated in 4 spots is probably okay.
- azanar 18y agoThe first of your two objections is perhaps a confusion of the word best practice. It doesn't mean ultimatum as much as it means something seriously worth considering. What constitutes "one thing" is a judgment call, and it varies tremendously as should be evident from all the other replies here trying to define it concretely. I imagine the definition changes a lot depending on how one's catalog of discrete things change. The point is not to define this "one thing" for you, it is to get you thinking about it. A lot of the best practices that have been put forth are the empirical outcome of repeated judgment calls by others. They notice a trend in their own practice, and put it forth as being more of an emergent principle than a coincidence. They might evangelize some, but it is a sign they are excited about the idea. It doesn't mean they don't know there are drawbacks; they might want to float the idea first and see if their concerns are legitimate. If I floated all of the possible drawbacks of ideas I've had, I'd probably scare people away, even though I overplayed a lot of them. Oh, and for the second objection, there is data. I don't have it in front of me, but I believe that Steve McConnell cites data within Code Complete about the length and scope of methods relative to error rate. Granted, one citation does not constitute proof, but it's a sign Uncle Bob isn't alone on his soapbox. :-) But then, the point of all of this evangelizing, really, is to get you off auto-pilot, and thinking about your work, not to give you the definitive answers to everything. That you asked this question shows you're thinking about it. Work hard to keep doing this, it's more important than any rule or best practice.
- tonystubblebine 18y agoYou are right that the place to go for data is Steve McConnell's Code Complete. He does a great job of summarizing whatever research is available.
- zmimon 18y agoI find a great way to understand the complexity you are coding into a method / function is to try and write a unit test for it. Short simple methods are easy to write tests for, while long, complex ones become exponentially harder to capture all the combinatorial state possibilities (eg: does it work when foo is null, but bar is not and baz is out of range? what about when bar is null but foo is not and baz is in range .... and so on.) Even if you are not intending to write a unit test for a particular function, it's useful to imagine how hard it would be to do so as a thought experiment.