Flotsam and Jetsam #103

  • Stefan Glienke

    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

    • Leonardo Herrera

      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.

        • Leonardo Herrera

          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.

          • Leonardo Herrera

            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”.)

          • David Heffernan

            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?

          • David Heffernan

            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?

          • David Heffernan

            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.

          • David Heffernan

            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”?

          • David Heffernan

            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?

          • David Heffernan

            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.

          • David Heffernan

            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.

          • David Heffernan

            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.

          • David Heffernan

            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.

          • David Heffernan

            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.

          • David Heffernan

            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. 🙂

          • David Heffernan

            You can’t seem to bring yourself to accept it. Indeed, you continue with the abuse. Manners please.

          • Gerry Coll

            In fact, IMHO can be much worse

        • Gerry Coll

          That is one of the main uses of nested procedures…
          The only major downside is that you can’t use them for function pointers.

          • Leonardo Herrera

            Yeah, but having a pointer to a nested function kind of defeats its purpose, don’t you think?

  • Jeff Dyer

    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.

    • Stefan Glienke

      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.

      • Jeff Dyer

        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”

  • Rudy Velthuis

    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.