Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Paul E. Bennett" Newsgroups: comp.lang.forth Subject: Re: comp.lang.forth.applications Followup-To: comp.lang.forth Date: Mon, 27 May 2013 23:34:47 +0100 Organization: Hidecs Consultancy Lines: 66 Message-ID: References: <519f3cd2.175876572@news.demon.co.uk> <519f4909$0$32116$14726298@news.sunsite.dk> Reply-To: Paul_E.Bennett@topmail.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7Bit X-Trace: individual.net Tje7L14KqBNw4Y7ByN5pcw/Ghu6ldLP4lSr28Nlv6cgaEWFDno Cancel-Lock: sha1:dCUj9nRlO9h2CeZLe/99Uw2AKbQ= Mail-Copies-To: Paul_E.Bennett@topmail.co.uk User-Agent: KNode/0.99.01 Xref: csiph.com comp.lang.forth:22974 Ed wrote: [%X] > I don't know whether Chuck ever wrote a program consisting of a > million lines of code, but he is certainly keen on keeping size > to a minimum. Can one write a million lines of efficient, error > free code? You tell me. Chuck may well have written a million lines by now but I am sure he hasn't done a million line programme. However, writing a million line programme is achievable in any language, even Forth. > My compiler source is 10,000 lines of assembler code and there > are times I feel I'm no longer in control of it. The larger the program, > the harder it becomes for a programmer to guarantee that a change > won't adversely affect something. I guess that's why they employ > testers and rely on users to find the bugs for them :) There are a few things that should be in place in order to write an error free application of any size. 1. You need to employ a development process that automatically produces teh evidence of its proper application. 2. Ensure that the components of the application connect ONLY via a well understood standard interface. 3. Embed the requirements statement for each function in the source code comments with full traceability to the original requirements. 4. By inspection ensure that the intent of the source code meets the statement of requirements. 5. Check all logical pathways of the function to ensure 100% coverage. 6. Once the code inspection and functional testing is completed satisfactorily, try and explore beyond the limitations to ensure sensible behaviour in spite of trying to break the function. 7. Use only the fully inspected and tested code (as in 4, 5 & 6) as components in your application. 8. Have and follow your coding style guidelines. From studies made, by my good friend Les Hatton, about testing time-frames increase with code size, functions beyond 300 lines of code take inordinately large time-scales to provide 100% coverage testing. So, the smaller the number of source code lines for a function the easier and quicker it is to fully test. So, the million line Forth programme, if constructed properly (with the above in mind), is likely to be of very high quality. It is something that seems to come easier in the Forth constructive mindset. But Forth programmes of such a size are only created because that size was essential to the application. -- ******************************************************************** Paul E. Bennett............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************