Timeline for Is it always a best practice to write a function for anything that needs to repeat twice?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 12, 2015 at 2:00 | comment | added | sdenham | @pllee You have just added another bit of confusion. You write " I said should I did not say always", but if you read my post, you will see that I actually wrote that the question, not you, says 'always' - the question, of course, being the text at the top of the page, towards which everything else on this page should be directed. So your first sentence in your last post says that the question is not dogmatic at all, but that seems at odds with what follows, where you argue that your position is more pragmatic than the one of the question - did you mean to say your view is not dogmatic? | |
| Nov 11, 2015 at 6:48 | comment | added | pllee |
No it is not dogmatic not at all, I really have no clue what you are arguing about. I said should I did not say always. Heck I even upvoted the comment about always and never before reading your answer. I also even mentioned it can be overkill. If you have any rebuttals or comments on the actual words written in my first comment I would love to hear them, I am always happy to learn.
|
|
| Nov 11, 2015 at 6:41 | history | edited | user22815 | CC BY-SA 3.0 |
deleted 6 characters in body
|
| Nov 11, 2015 at 4:21 | comment | added | sdenham | @pllee Nobody is claiming that small functions are not useful. The question is about the dogmatic claim that it is always right to make a function for anything repeated. Examples of or arguments for the former do not establish the latter, because it is universally quantified. The first sentence of your first reply looks like a claim that the dogma is right. If, instead of saying it 'should' be so, you meant to say that you think it is almost always feasible and useful to do this, then I would say I think you are overestimating the benefit in trivial cases such as those in the question. | |
| Nov 11, 2015 at 4:14 | history | edited | sdenham | CC BY-SA 3.0 |
Added an explanation of why small code fragments do not usually have independent meaning.
|
| Nov 10, 2015 at 15:50 | comment | added | pllee | I gave an example where even a single line statement can be more readable and I gave negatives of inlining code. That is my humble opinion and all I am saying and no I am not arguing against or talking about the "unnameable method". I am not really sure what is so confusing about that or why you think I need a "theoretical proof" for my opinion. I exampled improved readability. Maintenance is harder because if the code hunk changes it needs to in N number of spots (read about DRY). It is obviously harder to reuse unless you think copy paste if a viable way of reusing code. | |
| Nov 9, 2015 at 23:19 | comment | added | sdenham | @pllee You claim that it is "probably a bad sign" if you cannot find a significantly shorter, clearer name for almost every repeated code fragment, but that appears to be a matter of faith - you give no supporting argument (to make a general case, you need more than examples.) isWeekend does have a meaningful name, so the only way it could fail my criteria is if it is neither significantly shorter nor significantly clearer than its implementation. By arguing that you think it is the latter, you are asserting that it is not a counter-example to my position (FWIW, I have used isWeekend myself.) | |
| Nov 5, 2015 at 22:25 | comment | added | pllee |
I mentioned 3 negatives of inlining not sure where I merely claim it "should be different". All I am saying is that if you can't come up with a name your inline is probably doing too much. Also I think you are missing a big point here about even tiny once used methods. Tiny well named methods exist so you don't have to know what the code trying to do (no need to IDE jump). For example even the simple statement of ` if(day == 0 || day == 6) ` vs ` if(isWeekend(day))` becomes easier to read and mentally map. Now if you need to repeat that statement isWeekend becomes a no brainer.
|
|
| Jan 15, 2015 at 13:07 | comment | added | sdenham | @pllee : I have presented reasons why factoring into functions becomes counter-productive when taken to extremes (note that the question is specifically about taking it to extremes, not the general case.) You have offered no counter-argument to these points, but merely claim it 'should' be different. Writing that the naming problem is 'probably' a bad sign is not an argument that it is avoidable in the cases considered here (my argument, of course, is that it is at least a warning - that you may have reached the point of merely abstracting for its own sake.) | |
| Jan 14, 2015 at 21:39 | comment | added | pllee | Even if is the simplest of statements wrapping it in a function should make it more readable. There are times when wrapping it in a function is overkill but if you can't come up with a function name that is more concise and clear than what the statements are doing that is probably a bad sign. Your negatives for using functions aren't really a big deal imo. The negatives for inlining are a much bigger deal. Inlining makes it harder to read, harder to maintain, and harder to reuse. | |
| Jan 14, 2015 at 16:53 | history | answered | sdenham | CC BY-SA 3.0 |