Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!mucs!logitek!grep!frank From: frank@grep.co.uk (Frank Wales) Newsgroups: comp.software-eng Subject: Re: WANTED: "C" code line counter program Message-ID: <1991Mar28.145235.14313@grep.co.uk> Date: 28 Mar 91 14:52:35 GMT References: <1991Mar6.214157.18633@ntpal.uucp# <9082@suns6.crosfield.co.uk# <12630@pucc.Princeton.EDU> Reply-To: frank@grep.co.uk (Frank Wales) Organization: Grep Limited, LEEDS, UK Lines: 24 In article <12630@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: >Case in point: program A falls thru the cracks as a "noncomplicated >program" because it has only ONE statement. It fails. The >programmer assigned to fix it NOW opens it up and finds that >this "noncomplicated" program is one, 4096 byte, line of C >code containing a thousand statements. 4096 bytes on a line? Feh, kid's stuff. :-) Cases like this (fictitious or not) seem to me to highlight the problems of metrics like "lines of code" or "statement counts", because these are predicated on the notion that statements or lines are uniformly complex, fundamental pieces from which programs are built. It's hard for me to accept such a notion for anything other than assembly language. Quite apart from the difficulties associated with inter-language comparisons, is there any work on enumerating programs at the token level, a sort of "component count" metric? This, at least, would be an honest assessment of the fundamental syntactic pieces, whatever that might be worth. (Yes, I'm a "metric sceptic".) -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303