Subject: RE:malloc etc. on DEC Alpha

From: "Simon Kilvington" <[email-masked]>
Date: Fri, 17 Mar 1995 09:23:17 +0000 (GMT)

>Unfortunately, many programmers (especially among scientists) still
>think that it is sufficient to run a few test cases to validate their
>programs. What one should do, and what many people in other fields are
>already doing, is to think about debugging from the beginning of the
>design process. Whenever your start to write a piece of code, your
>first thought should be "How can I check whether I have made a
>mistake?" Every program unit should be able to test the validity of
>to remove the tests from production code. Choose variable and function
>names that are sufficiently different from one another that typos can
>be caught by the compiler. Use all available tools for checking your
>code (ftncheck for Fortran, lint for C), and make use of all compiler
>options that help in debugging (i.e. -C with f77). I could extend this
>list, but all this has been published before. Whoever really wants
>to write reliable code can do so with little effort.
>
>For some reasons that I cannot follow, scientists seem to ignore the
>considerable progress that has been made in software engineering
>during the last decades. Even big and much-used packages are in such a
>bad shape that they seem to have been written by first-year students
>as a programming exercise. I have heard excuses such as "I don't have
>time to learn about programming techniques", but the people saying
>that seem to have enough time to waste it on endless debugging and
>on running programs whose results cannot be trusted.
>I have been working in commercial software development (non-
>scientific) for more than a decade, and I am sure my
>company would have been out of business long out if it had
>this "scientific" attitude towards software development.
>

	you should all read a book called "Code Complete" by Steve
McConnell, published by the Microsoft Press.

	to quote from the preface:

The research and programming experience collected in this handbook will
help you to create higher-quality software and to do your work more quickly
and with fewer problems. This book will give you insight into why you've had
problems in the past and will show you how to avoid them in the future. The
programming practices described here will help you keep big projects under
control and help you maintain and modify software successfully as the
demands of your projects change.

	Si.

---
Simon Kilvington, [email-masked]

---

From: [email-masked] (Hinsen Konrad)
Date: Fri, 17 Mar 95 11:07:03 -0500

"Simon Kilvington" <[email-masked]> wrote:

An excellent suggestion!

Be warned, however, that this book is written for C programmers.
Although many topics discussed in it are equally valid for programming
in Fortran or any other "standard" programming language, you probably
need some basic knowledge of C to profit from the book.

However, it doesn't hurt to know something about C anyway, even
if you don't intend to use it much. One of the best introductions
to C for those who already know some other programming language
is still the good old Kernighan & Ritchie ("The C Programming
Language", by B. Kernighan and D. Ritchie; make sure to get the
second edition that deals with ANSI C).

I remember having seen a book that deals with good programming style
in Fortran, but I do not have a reference. Many Fortran textbooks
unfortunately give a lot of bad advice - often for the sake of
"efficiency", but most of these tricks give no advantages with most
modern compilers.

Obviously it is much more difficult to write safe code in Fortran,
since you have to deal with all the silly limitations of a stone-age
language. This makes it all the more important to have tools to help
you, and by far the most important one is ftnchek (available from
AT&T's netlib), which checks your for semantic errors that compiler
normally don't detect (like passing wrong parameters to subroutines).
It's free, it works, and it is easy to use - so there is no
excuse for not using it.

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: [email-masked]
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. A                | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------

---

From: Pat Walters <[email-masked]>
Date: Fri, 17 Mar 1995 11:32:05 -0700 (MST)

I can't resist throwing in my $0.02 on this subject.

In addition to "Code Complete" I'd recommend

Writing Solid Code
Steve Maguire
Microsoft Press
ISBN 1-55615-551-4

Also ...

There is an excellent commercial package called MemCheck which can
be a tremendous aid in debugging malloc problems.  Not only will MemCheck 
find things like overwrites, it will also find "leaks" caused by
memory you forgot to free.

MemCheck is available for Unix, DOS and Windows.  It costs about $200.00
(cheaper if you ask for an academic discount), and it's worth every cent.

You can get MemCheck from StratosWare (1-800-WE-DEBUG).

My only association with StratosWare is as a VERY satisfied customer.

Pat

_________________________________________________________________________
W. Patrick Walters                 [email-masked]
Graduate Student       http://mercury.aichem.arizona.edu/pat.html
Laboratory for Artificial Intelligence in Chemistry    *
Dept of Chemistry                                    * * *  
University of Arizona, Tucson  AZ 85721              * * * 
Voice : 602-621-6334   FAX :  602-621-8407            ***
"At least it's a dry heat"                             * 
_______________________________________________________*__________________