Timeline for How small should functions be?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 10, 2017 at 17:55 | comment | added | Basile Starynkevitch | In some cases, a function of a thousand lines might make good sense. There is no absolute rule. For example, the layout of widgets inside a window might take a lot of lines, but is really trivial to read. | |
| Jun 6, 2017 at 1:16 | comment | added | Marco13 |
@FrankHileman I thought something similar. How about creating functions like MOV, ADD, SHL ... hey .. wait...: That indeed does not make sense.
|
|
| Jun 6, 2017 at 1:08 | comment | added | Frank Hileman | "As small as possible" could just mean adding more and more functions instead of more lines of code.... it is possible to add functions that simply call another function. There is no reason for this. | |
| Jun 5, 2017 at 23:50 | comment | added | John Wu | Let us continue this discussion in chat. | |
| Jun 5, 2017 at 23:39 | comment | added | candied_orange | It is irrelevant. You can't do anything with functions that I can't do without them. All I need is a stack and goto. Abstraction is for the humans not the computer. Can we do this in chat because this is getting silly. | |
| Jun 5, 2017 at 23:30 | comment | added | John Wu | Don't need to, I'm well aware that braces can define an inner scope. That is only half the issue. There is no way to define an outer scope without promoting a variable to member or global scope (unless you count closures). If you have a long function that uses the same local variables throughout, it becomes difficult to break into smaller functions. That is why I say it is not irrelevant to your choice of how to break up your code. | |
| Jun 5, 2017 at 23:10 | comment | added | candied_orange | Try reading the link I provided | |
| Jun 5, 2017 at 23:09 | comment | added | John Wu | Doesn't a function begin and end with curly braces? Also, bear in mind that the OP hasn't tagged a specific language. | |
| Jun 5, 2017 at 23:00 | comment | added | candied_orange | Oh come on. Scope isn't determined by function definitions. It's determined by curly braces. | |
| Jun 5, 2017 at 21:39 | comment | added | John Wu | I am glad you agree there is such a thing as correct and incorrect scoping. Since scope is determined by the boundary of function definitions, that means that there is such a thing as correct and incorrect function definition. This disproves the proposition that function definition "has nothing to do with the work being done." That is my only point. I agree that good naming is extremely important, and that poor naming is an indicator of an abstraction that is poorly thought out. | |
| Jun 5, 2017 at 21:20 | comment | added | candied_orange | That's not correctly scoping. Correctly scoping is not forcing an identifier to live longer than it is needed. Using one scope doesn't make the method large. The work to be done does. Without some abstraction that's not going away. The flat scope just makes the namespace of the scope cluttered with every name. But look I'm already maxed today. Why don't you beef up your answer. You almost have me beat. | |
| Jun 5, 2017 at 20:53 | comment | added | John Wu | You're missing my point. Scoping is an issue that may prevent you from keeping methods small, so saying that size "has nothing to do with" what is going on in the function is too strong a statement, and probably misleading. As for naming, if we are comparing apples to applies, I'd rather have a few badly named small functions than one badly named large function, because I can parse meaning out of the code more easily when the logic is well-structured. | |
| Jun 5, 2017 at 20:32 | comment | added | candied_orange | When you keep methods small scoping is a non issue. If you don't keep them small nameless scopes are better than abhorrently named methods. Flow control, if you don't use polymorphism to make it go away, should be made simple and flat even if you aren't messing with tiny methods. Structure and abstraction are simply not the same thing. I can structure code correctly without even thinking up new names. Without a good name good abstraction eludes me every time. | |
| Jun 5, 2017 at 20:15 | comment | added | John Wu | Has nothing to do with work being done? What about control of scope and control of flow? | |
| Jun 5, 2017 at 18:52 | history | answered | candied_orange | CC BY-SA 3.0 |