3 ms·

You shouldn't have to jump around, because the function names tells you exactly what it does according to reasonable expectations. You can just skip over it, if

You shouldn't have to jump around, because the function names tells you exactly what it does according to reasonable expectations. You can just skip over it, if your not interested in its work. If your function does an unexpected side effect, thats a problem with the code. Not with the idea of writing functions that do a specific thing. I can't help but think people who complain about this, are just bad at creating functions at the correct level of abstraction. It's also why i'm a functional fan, because it makes it more difficult for functions to do unexpected things.

ubercow13 6y ago
>I can't help but think people who complain about this, are just bad at creating functions at the correct level of abstraction. They are complaining due to difficulty of reading other peoples' code, not their own.
- UK-Al05 6y ago
  A well named function is easier to read, then having work out the intent behind some low level code.
ratww 6y ago
I think you might have misunderstood my post. I'm not advocating having large functions over smaller functions. What I'm advocating is instead of breaking functions based purely on a visual criteria or by grouping functionality, it's better to use proper abstractions when breaking the function. > You can just skip over it The point is that if I blindly break a larger functions by functionality, I still have to understand the deeper functionality. So, I can't just skip when I'm debugging or deeply reviewing/inspecting the code, or doing a rewrite or trying to understand it. > I can't help but think people who complain about this, are just bad at creating functions at the correct level of abstraction. My point was exactly that you should create functions at the correct level of abstraction, rather than just splitting large functions purely by functionality, like you would with a cooking recipe. > If your function does an unexpected side effect, thats a problem with the code But this is exactly what I'm trying to avoid. If you need side effects, keep them visible, by keeping them in the main function, instead of just blindly putting them into smaller functions.
- UK-Al05 6y ago
  > The point is that if I blindly break a larger functions by functionality, I still have to understand the deeper functionality. So, I can't just skip when I'm debugging or deeply reviewing/inspecting the code, or doing a rewrite or trying to understand it. That's exactly what a well abstracted function should let you do. It only comes difficult with global state, and unexpected side effects. You should break up functions by intent.
dagw 6y ago
function names tells you exactly what it does according to reasonable expectations. You can just skip over it, if your not interested in its work. I understand the argument to be that by breaking everything out into functions it makes it too easy to hide what is actually going on and you can miss a lot of fine detail. If your code looks like x=doA(); y=doB(x); z=doC(y); then it becomes very hard to spot for example that both functions doA and doC recomputed the same intermediate value that you could just compute once and reuse or that doB validates its input, but in this case you know it's unnecessary to do so, since you know that doA can only return data that is valid for doB. If everything was inline then these things would jump out at you a lot quicker. Of course in many cases this doesn't matter and recomputing that intermediate value twice costs so little in the grand scheme of things that the extra readability is worth it.
- UK-Al05 6y ago
  Yes, but these about micro optimisation for video games. People here are complaining about this in standard situations. Where being able quickly grasp what function is doing is far more important then identifying recomputed work.

ubercow13 6y ago

>I can't help but think people who complain about this, are just bad at creating functions at the correct level of abstraction. They are complaining due to difficulty of reading other peoples' code, not their own.

UK-Al05 6y ago
A well named function is easier to read, then having work out the intent behind some low level code.

ratww 6y ago

I think you might have misunderstood my post. I'm not advocating having large functions over smaller functions. What I'm advocating is instead of breaking functions based purely on a visual criteria or by grouping functionality, it's better to use proper abstractions when breaking the function. > You can just skip over it The point is that if I blindly break a larger functions by functionality, I still have to understand the deeper functionality. So, I can't just skip when I'm debugging or deeply reviewing/inspecting the code, or doing a rewrite or trying to understand it. > I can't help but think people who complain about this, are just bad at creating functions at the correct level of abstraction. My point was exactly that you should create functions at the correct level of abstraction, rather than just splitting large functions purely by functionality, like you would with a cooking recipe. > If your function does an unexpected side effect, thats a problem with the code But this is exactly what I'm trying to avoid. If you need side effects, keep them visible, by keeping them in the main function, instead of just blindly putting them into smaller functions.

UK-Al05 6y ago
> The point is that if I blindly break a larger functions by functionality, I still have to understand the deeper functionality. So, I can't just skip when I'm debugging or deeply reviewing/inspecting the code, or doing a rewrite or trying to understand it. That's exactly what a well abstracted function should let you do. It only comes difficult with global state, and unexpected side effects. You should break up functions by intent.

dagw 6y ago

function names tells you exactly what it does according to reasonable expectations. You can just skip over it, if your not interested in its work. I understand the argument to be that by breaking everything out into functions it makes it too easy to hide what is actually going on and you can miss a lot of fine detail. If your code looks like x=doA(); y=doB(x); z=doC(y); then it becomes very hard to spot for example that both functions doA and doC recomputed the same intermediate value that you could just compute once and reuse or that doB validates its input, but in this case you know it's unnecessary to do so, since you know that doA can only return data that is valid for doB. If everything was inline then these things would jump out at you a lot quicker. Of course in many cases this doesn't matter and recomputing that intermediate value twice costs so little in the grand scheme of things that the extra readability is worth it.

UK-Al05 6y ago
Yes, but these about micro optimisation for video games. People here are complaining about this in standard situations. Where being able quickly grasp what function is doing is far more important then identifying recomputed work.