Another entry in the “They are evil” category: nested routines. Just don’t. In my codebase at work, there are methods that six, seven, even eight nested methods. I have even seen nested routines with nested routines. Argh. Despite being a formatting nightmare – how are you supposed to read and understand that? – a bunch of nested routines screams “Make me into a class”. If you have a bunch of methods at all should be grouped together, isn’t that pretty much the definition of what a class is? Anyway, nested routines should be banished.
38 Replies to “Flotsam and Jetsam #103”
Yay, one more of Nicks absolute statements just because he does not like something.
You do realize that you can have nested routines that make code cleaner (yes, certainly not 6 levels deep ones. But in such code I guess these nested routines are the least of your problems…) and you cannot just make them regular methods because they might access local variables or parameters which might be more effective than passing them to the routine.
Bottom line: use the tools you have wisely.
“Bottom line: use the tools you have wisely.”
I completely agree. ;-0
Nested routines help making long procedures more readable, when there makes no sense to create a bunch of reusable methods in the class body. I find them useful where extension methods would have been useful…
“Long procedures” should be banned as well. Refactor them to small procedures.
Having not-reusable private procedures all over the place that aren’t called except in one tiny place is not much better than having nested procedures.
Ahh, but better they are nonetheless.
Your opinion. If there is a lot of transitive data to be manipulated you’d have to either create a lot of properties that won’t benefit the overall design of your class or pass lots of arguments around. As I said, “when it makes no sense to create a bunch of (non) reusable methods in the class body” (I meant to say “non-reusable”.)
Not always. Replacing nested functions with private methods is a scope creep. Nested functions can only be called from the function in which they are nested. Private methods can be called from any method of the class in which they are declared. Thus you are advocating broadening the scope of the functions needlessly.
I don’t really understand why you believe that programmers are too stupid to use their own judgement. Do you really program without thinking, only by following rules?
I don’t really understand why you believe that programmers should just do whatever and not use sound guildelines. Do you really program whatever, without any rules to guide your work? Do you let junior programmers do whatever they feel like without giving them some rules to follow?
Well, I don’t believe that at all. It’s not a simple dichotomy. Guidelines are good. But dogmatic rules that must never be broken make no sense to me. Unlike you I don’t believe that programming can be condensed into a set of rules. I believe that different problems require different solutions and approaches.
You ignored my point about scopes.
I set like four rules, and your conclusion is that I’ve condensed *all of* programming into a set of rules? I don’t believe that, so you’ve drawn an incorrect solution — as usual, I should note. I don’t believe any such thing. Get real.
I’m sorry you can’t understand why, sometimes, “dogmatic rules” make sense. Sometimes they do. For instance, I have a dogmatic rule: “Never use manual binary coding when Object Pascal will do the trick.” Is that a “dogmatic” rule you can understand? Here’s another one: “Never code an entire Windows application using a hex editor” How about that one? Do you get that?
Who doesn’t believe that “different problems require different solutions and approaches”. That’s pure pablum, really. Of course it’s true. Everyone believes that.
Your point about scopes was correct. Feel better?
No, that’s not dogmatic. That is common sense. But your assertion that there are no scenarios where nested functions are good is dogma. In my opinion. In my opinion much of what you claim to be incontrovertibly true is not so.
In my opinion it’s not dogma but common sense. To each his own is fine by me.
Plus, you use the word “dogma” like it’s a bad thing.
I’d say that faith based programming was a bad thing. I think that, as a general rule, evidence provides a better basis for decision making than dogmatic faith.
Who said anything about “faith”?
It seems that you don’t understand the meaning of the word dogma.
From Google: “a principle or set of principles laid down by an authority as incontrovertibly true.” No mention of faith anywhere.
Who doesn’t understand the definition again?
Now you are trolling. Perhaps you don’t know what faith means.
You really don’t like to admit it when you are wrong, do you.
Actually, I think I can do that quite well. You read the Wikipedia article then? From top to bottom? You don’t see any connection between dogmatic beliefs and faith?
Sure, there is a connection, and sure the word is used in connection with religion. But the definition itself — that is, the actual meaning of the word — doesn’t mention anything about faith.
I’m happy to have my beliefs about programming to be elevated to the level of dogma — using the actual definition, not the implied one — by you. Shows you consider me an authority.
I’m not using the word faith to imply anything religious. I use faith to refer to beliefs held without evidence.
Dogmatic opinions are, in my view, often worthless.
No, I do not consider you to be an authority. Much of what you write seems to me to be dogmatic. Made worse by your presentation of your opinions as being absolute truths. You often make reasonable points, but by over-stating them, you can invalidate them.
Ahh — suddenly I get it. You completely lack a sense of humor, and thus don’t understand the slight tongue in cheek tone of my comments. This explains so much.
You mean that when you said that nested functions should never be used, you actually meant something else.
If that was meant to be funny, then I think it is true that at least one of us has a deficient sense of humour.
No, no need to be self-deprecating. Utterly lacking in humor is a common trait. Nothing to be ashamed of. I just didn’t realize it. My apologies.
Personal abuse, way off topic. Not something to be proud of. Playground stuff.
All I did was disagree with you, and this is what it comes to.
Time to learn some basic manners.
LOL — thanks for proving my point. You have a great evening, David.
All I can see here is that you’ve shown yourself to be rude and offensive. Not something to be proud of.
I’m *quite* certain that is all you can see here. 🙂
You can’t seem to bring yourself to accept it. Indeed, you continue with the abuse. Manners please.
In fact, IMHO can be much worse
That is one of the main uses of nested procedures…
The only major downside is that you can’t use them for function pointers.
Yeah, but having a pointer to a nested function kind of defeats its purpose, don’t you think?
This bias against “with” is frankly ridiculous.
If you are writing “old fashioned” code to execute several queries against a database, writing something like
with CustomerQuery do
begin
SQL.Clear;
SQL.Add(‘SELECT * FROM customers’);
SQL.Add(‘WHERE ID = ‘ + IntToStr(CustID));
ExecSQL;
end;
with CaseQuery do
begin
same
end;
etc it makes a lot of sense to not have to repeat the query name over and over.
Actually it would make more sense to put CustomerQuery.SQL into a variable and use that. Or not use .Add but define a const SQL statement where you fill in the values and then just set SQL.Text. Or even better use Parameters for less SQL injection danger (not in this example) and better execution plans.
Would it make more sense? Obviously that was an example, a CONST is not an option. I always use parameters for strings thanks. Using parameters would require the query to be specified for each parameter, a classic candidate for “with”
Not only do I agree with David Heffernan, but there is another good reason for them.
Delphi lacks block local scope. This can be overcome by a nested routine. I had a problem with code being slow due to an implicit try finally around the entire routine, even if that was only required for a block in the routine that was not called very often. Putting that block into its own nested routine removed the try finally on the outer routine and moved it to the nested routine.
But also for utility functions that are used several times in an outer routine, they can be very useful.
Yay, one more of Nicks absolute statements just because he does not like something.
You do realize that you can have nested routines that make code cleaner (yes, certainly not 6 levels deep ones. But in such code I guess these nested routines are the least of your problems…) and you cannot just make them regular methods because they might access local variables or parameters which might be more effective than passing them to the routine.
Bottom line: use the tools you have wisely.
“Bottom line: use the tools you have wisely.”
I completely agree. ;-0
Nested routines help making long procedures more readable, when there makes no sense to create a bunch of reusable methods in the class body. I find them useful where extension methods would have been useful…
“Long procedures” should be banned as well. Refactor them to small procedures.
Having not-reusable private procedures all over the place that aren’t called except in one tiny place is not much better than having nested procedures.
Ahh, but better they are nonetheless.
Your opinion. If there is a lot of transitive data to be manipulated you’d have to either create a lot of properties that won’t benefit the overall design of your class or pass lots of arguments around. As I said, “when it makes no sense to create a bunch of (non) reusable methods in the class body” (I meant to say “non-reusable”.)
Not always. Replacing nested functions with private methods is a scope creep. Nested functions can only be called from the function in which they are nested. Private methods can be called from any method of the class in which they are declared. Thus you are advocating broadening the scope of the functions needlessly.
I don’t really understand why you believe that programmers are too stupid to use their own judgement. Do you really program without thinking, only by following rules?
I don’t really understand why you believe that programmers should just do whatever and not use sound guildelines. Do you really program whatever, without any rules to guide your work? Do you let junior programmers do whatever they feel like without giving them some rules to follow?
Well, I don’t believe that at all. It’s not a simple dichotomy. Guidelines are good. But dogmatic rules that must never be broken make no sense to me. Unlike you I don’t believe that programming can be condensed into a set of rules. I believe that different problems require different solutions and approaches.
You ignored my point about scopes.
I set like four rules, and your conclusion is that I’ve condensed *all of* programming into a set of rules? I don’t believe that, so you’ve drawn an incorrect solution — as usual, I should note. I don’t believe any such thing. Get real.
I’m sorry you can’t understand why, sometimes, “dogmatic rules” make sense. Sometimes they do. For instance, I have a dogmatic rule: “Never use manual binary coding when Object Pascal will do the trick.” Is that a “dogmatic” rule you can understand? Here’s another one: “Never code an entire Windows application using a hex editor” How about that one? Do you get that?
Who doesn’t believe that “different problems require different solutions and approaches”. That’s pure pablum, really. Of course it’s true. Everyone believes that.
Your point about scopes was correct. Feel better?
No, that’s not dogmatic. That is common sense. But your assertion that there are no scenarios where nested functions are good is dogma. In my opinion. In my opinion much of what you claim to be incontrovertibly true is not so.
In my opinion it’s not dogma but common sense. To each his own is fine by me.
Plus, you use the word “dogma” like it’s a bad thing.
I’d say that faith based programming was a bad thing. I think that, as a general rule, evidence provides a better basis for decision making than dogmatic faith.
Who said anything about “faith”?
It seems that you don’t understand the meaning of the word dogma.
From Google: “a principle or set of principles laid down by an authority as incontrovertibly true.” No mention of faith anywhere.
Who doesn’t understand the definition again?
Now you are trolling. Perhaps you don’t know what faith means.
http://en.wikipedia.org/wiki/Dogma
You really don’t like to admit it when you are wrong, do you.
Actually, I think I can do that quite well. You read the Wikipedia article then? From top to bottom? You don’t see any connection between dogmatic beliefs and faith?
Sure, there is a connection, and sure the word is used in connection with religion. But the definition itself — that is, the actual meaning of the word — doesn’t mention anything about faith.
I’m happy to have my beliefs about programming to be elevated to the level of dogma — using the actual definition, not the implied one — by you. Shows you consider me an authority.
I’m not using the word faith to imply anything religious. I use faith to refer to beliefs held without evidence.
Dogmatic opinions are, in my view, often worthless.
No, I do not consider you to be an authority. Much of what you write seems to me to be dogmatic. Made worse by your presentation of your opinions as being absolute truths. You often make reasonable points, but by over-stating them, you can invalidate them.
Ahh — suddenly I get it. You completely lack a sense of humor, and thus don’t understand the slight tongue in cheek tone of my comments. This explains so much.
You mean that when you said that nested functions should never be used, you actually meant something else.
If that was meant to be funny, then I think it is true that at least one of us has a deficient sense of humour.
No, no need to be self-deprecating. Utterly lacking in humor is a common trait. Nothing to be ashamed of. I just didn’t realize it. My apologies.
Personal abuse, way off topic. Not something to be proud of. Playground stuff.
All I did was disagree with you, and this is what it comes to.
Time to learn some basic manners.
LOL — thanks for proving my point. You have a great evening, David.
All I can see here is that you’ve shown yourself to be rude and offensive. Not something to be proud of.
I’m *quite* certain that is all you can see here. 🙂
You can’t seem to bring yourself to accept it. Indeed, you continue with the abuse. Manners please.
In fact, IMHO can be much worse
That is one of the main uses of nested procedures…
The only major downside is that you can’t use them for function pointers.
Yeah, but having a pointer to a nested function kind of defeats its purpose, don’t you think?
This bias against “with” is frankly ridiculous.
If you are writing “old fashioned” code to execute several queries against a database, writing something like
with CustomerQuery do
begin
SQL.Clear;
SQL.Add(‘SELECT * FROM customers’);
SQL.Add(‘WHERE ID = ‘ + IntToStr(CustID));
ExecSQL;
end;
with CaseQuery do
begin
same
end;
etc it makes a lot of sense to not have to repeat the query name over and over.
Actually it would make more sense to put CustomerQuery.SQL into a variable and use that. Or not use .Add but define a const SQL statement where you fill in the values and then just set SQL.Text. Or even better use Parameters for less SQL injection danger (not in this example) and better execution plans.
Would it make more sense? Obviously that was an example, a CONST is not an option. I always use parameters for strings thanks. Using parameters would require the query to be specified for each parameter, a classic candidate for “with”
Not only do I agree with David Heffernan, but there is another good reason for them.
Delphi lacks block local scope. This can be overcome by a nested routine. I had a problem with code being slow due to an implicit try finally around the entire routine, even if that was only required for a block in the routine that was not called very often. Putting that block into its own nested routine removed the try finally on the outer routine and moved it to the nested routine.
But also for utility functions that are used several times in an outer routine, they can be very useful.