From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92c39a3be0a7f17d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-11 15:00:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!elk.ncren.net!nntp.upenn.edu!msunews!not-for-mail From: "Chad R. Meiners" Newsgroups: comp.lang.ada Subject: Re: Future with Ada Date: Mon, 11 Mar 2002 17:53:55 -0500 Organization: Michigan State University Message-ID: References: <3C7E7CAD.7070504@mail.com> <3C7FB9D2.D9C6E055@boeing.com> <3C81DF1F.9000503@mail.com> <3C83A112.6080302@mail.com> <3C84223C.A356F466@adaworks.com> <3C853A04.34826F39@despammed.com> Reply-To: "Chad R. Meiners" NNTP-Posting-Host: arctic.cse.msu.edu X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:21087 Date: 2002-03-11T17:53:55-05:00 List-Id: I see. I agree that there are many cases where subroutine logic should be broken into smaller subroutines, but I have also encountered many subroutines in which the additional nesting within contains a small set of atomic actions so the cost of switching your mindframe to peek into another subroutine is greater than the cost of the additional level of nesting. "Kevin Cline" wrote in message news:dcfe911f.0203111043.53a94cc4@posting.google.com... > "Chad R. Meiners" wrote in message news:... > > "Kevin Cline" wrote in message > > news:dcfe911f.0203071252.582e0401@posting.google.com... > > > > > I used to happily program this way until I realized people > > > (including me, after a few weeks) > > > trying to read my code were drowning in details. Now I limit > > > myself to one level of nesting per function, unless some > > > performance analysis proves the function call overhead is too great. > > > > > > It's true that the complexity has to be somewhere, but it's not necessary > > > nor desirable that it all be in one place. > > > > > I find it much easier to understand five ten-line functions > > > than to understand one fifty-line function. > > > > If you had read the post you are replying to carefully, you would have > > realized that the Marin is not advocating a practice that requires you to > > always favor using deeply nested if statements. He is stating that there > > are cases in which using nested if statements is the most appropriate > > solution. > > > > You seem to be stating that there is never a case is which nested ifs are > > appropriate (barring speed constraints). I find this claim very difficult > > to believe. Is this the claim you really want to be making? > > That's pretty much it. Functions with nested ifs are hard to code > correctly, > and hard to understand. Worst, they're hard to test competely. A > single function is the smallest unit that can be tested. Separating > the top-level branches into separate functions allows each branch to > be tested separately. > > Some people may enjoy painstakingly creating and verifying a complex > function. > I find that my accuracy improves if I write several small functions > that > can be easily read and tested. > > Additionally, I find that it's very often the case that a set of > nested ifs would be better expressed in another way -- perhaps via > data and a simple > lookup function, or as a set of subclasses. I find that breaking up > the > function makes the overall structure more apparent.