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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e94a7e4f6f888766 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Self-referential types Date: 1999/10/22 Message-ID: <3810CCC8.E4CB47C4@mitre.org>#1/1 X-Deja-AN: 539391511 Content-Transfer-Encoding: 7bit References: <7ttb4a$8mq$1@nnrp1.deja.com> <3802f2db_2@news1.prserv.net> <3803B5E3.F96A6DD4@mitre.org> <3803c8bc_2@news1.prserv.net> <3804E7E0.6A0265FB@mitre.org> <38077EB3.E6911567@mitre.org> <7u86su$o5v$1@nntp8.atl.mindspring.net> <380BA036.E9F51F22@mitre.org> <7uq8g3$jl8$1@nntp5.atl.mindspring.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.mitre.org X-Trace: top.mitre.org 940624782 3394 129.83.41.77 (22 Oct 1999 20:39:42 GMT) Organization: The MITRE Corporation Mime-Version: 1.0 NNTP-Posting-Date: 22 Oct 1999 20:39:42 GMT Newsgroups: comp.lang.ada Date: 1999-10-22T20:39:42+00:00 List-Id: Richard D Riehle wrote: > As you so carefully note in your > message, this does require some planning. In a large-scale development > effort, planning at this level of detail is often absent from the > process. I think that this really sums it all up. Fortunately less often recently, I get put on "Red Teams" to decide if some project can be saved, and if so how. (And for how much, or whether it is better to cancel it anyway.) So from my experience, too many nested procedures is an indication of (very) bad design. As I also said, nested functions, usually small, don't seem to imply bad design, but nested procedures do. If I were to make this a serious metric by itself, I would use something like, for each procedure start with zero. Climb to the root, and for each nesting, if inside another subprogram or task entry add one. Sum over all procedures and divide by the number of procedures to normalize. I could then set up a scale: 0.1 or less very good,...0.5 acceptable, >1.5 reject. I don't for two reasons. First I have some coupling measures which do a better job, and second, you don't need a scale. Most code is either near zero, around one, or over three... In fact, MITRE did do a lot of work on coupling and cohesion measures using DIANA a few years ago--I would lie to update the tools to use ASIS. But in reality, these tools were of no use at all. The results were either, "Gee, this is just short of perfection, can you do anything about package XXX?" or "This code sucks, but you knew that just from the effort to get it processed by the front-end of the tool. There is no reason to tell you where it sucks or how to fix it. But if you care the answers are 'everywhere' and 'don't'." Incidently, I took a look at some of the GNAT library packages. For almost all of them, the count as expressed above would be zero. The exceptions? Explicit finite state such as in GNAT.Regexp, where such structure is completely justified. But while Robert Dewar and I may write such code, most programmers never do. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...