---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A9A519C90214; Thu, 29 Jan 2004 11:06:13 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CC2FB3@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 14:05:54 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 8901 for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 14:05:48 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8587; Thu, 29 Jan 2004 14:05:04 -0500 Received: from todd.digitalwest.net [216.111.116.242] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with SMTP ; Thu, 29 Jan 2004 14:05:03 EST X-Comment: mitvma.mit.edu: Mail was sent by todd.digitalwest.net Received: (qmail 16489 invoked from network); 29 Jan 2004 19:05:05 -0000 Received: from unknown (HELO kauko.hallikainen.org) (63.194.113.64) by 0 with SMTP; 29 Jan 2004 19:05:05 -0000 Received: from kauko.hallikainen.org (localhost.localdomain [127.0.0.1]) by kauko.hallikainen.org (8.12.8/8.12.8) with ESMTP id i0TJ558O020568 for ; Thu, 29 Jan 2004 11:05:05 -0800 Received: (from apache@localhost) by kauko.hallikainen.org (8.12.8/8.12.8/Submit) id i0TJ54sg020566; Thu, 29 Jan 2004 11:05:04 -0800 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-Authentication-Warning: kauko.hallikainen.org: apache set sender to harold@hallikainen.com using -f Received: from 207.177.227.29 (SquirrelMail authenticated user harold) by kauko.hallikainen.org with HTTP; Thu, 29 Jan 2004 11:05:04 -0800 (PST) References: <2193429B07D9914D97216EBBAA6AB8BD1A0509@whitlam.corp.gli.com.au> <5.2.0.9.2.20040129073858.01554480@mail.cedar.net> <5.2.0.9.2.20040129124239.015f7178@mail.cedar.net> <000d01c3e693$98693ac0$0300a8c0@main> User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Message-ID: <32385.207.177.227.29.1075403104.squirrel@kauko.hallikainen.org> Date: Thu, 29 Jan 2004 11:05:04 -0800 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Harold Hallikainen Subject: Re: [PIC:] Process To: PICLIST@MITVMA.MIT.EDU In-Reply-To: <000d01c3e693$98693ac0$0300a8c0@main> Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856310 Interesting discussion. I'm not that formal in my work. Since the company is small, there is no one to do peer review. Years and years ago I went to a seminar put on by Forth, Inc. Though I never did much with Forth, I have adopted one of their ideas, and I use it in both hardware and software. That is, get the small parts working, then connect them together (bottom up coding). I first get code that talks to the hardware working. Next comes code that calls that code. Next is code that calls that code, etc. You do this in Forth by defining new "words" based on words that are already in the Forth dictionary. As you define each new word, you test it. Then you move on. Eventually, you have a Forth word that is the complete application. Of course, I have an idea of what the final application needs to do, the user interface, etc. I'm just starting at the bottom and heading in that direction instead of starting at the top and heading down. Advocates of top down programming don't like this approach, but it's what I use. It's probably my hardware orientation. The other thing I like is COMMENTS! I type fast enough that the time to add comments is minimal. The top of each subroutine or function describes what the function does (the gazinta and the gazouta), what its side effects are (ideally none, but you often mess with registers in assembly), and the "design philosophy" (WHY is it done this way, URLs of references, etc.). As I think about the process while writing a line of code, the thought goes in a comment on that line. What does this line do? Why is it here? These help me a lot when I go back a year later trying to add features. The first class I taught was PDP-8 assembly language. I had students add comments to their code after they got it working. Of course, by then, they didn't really remember how the code worked, so the comments and the code disagreed. Not super helpful. We work with contract programmers for Windoze applications. While they may feel their code is self documenting, not needing comments, I can't read their code! When their ap needs to talk with my PIC, they can read my PIC assembly code (even they don't know PIC assembly) and figure out what needs to be done. Comments!!! Harold -- FCC Rules Online at http://www.hallikainen.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. .