Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] [OT] Appeal to save the comments inside the code

Expand Messages
  • Ron Jeffries
    Hello, Chris. On Wednesday, October 1, 2008, at 6:50:37 AM, you ... Given that it is something we don t have time to explore deeply, what /is/ your preferred
    Message 1 of 49 , Oct 1, 2008
    • 0 Attachment
      Hello, Chris. On Wednesday, October 1, 2008, at 6:50:37 AM, you
      wrote:

      > The clincher here, of course, is the 'if it triggers' clause. If it never
      > triggers before leaving the dev shop, and then starts triggering at customer
      > sites, well, I know my customers aren't as accommodating of my testing needs
      > as I'd like them to be. That's why I think this option is a dangerous one.

      Given that it is something we don't have time to explore deeply,
      what /is/ your preferred option? I seem to have missed it in all the
      excitement.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Reason is and ought only to be the slave of the passions. -- David Hume
    • Nancy Van Schooenderwoert
      ... In my work with embedded software, including safety critical systems, I found that I wanted 2 modes of behavior on an assert failure: 1. In development It
      Message 49 of 49 , Oct 24, 2008
      • 0 Attachment
        Jeff Grigg wrote:
        > --- John Carter <john.carter@...> wrote:
        >> What should an assert statement do on failure?
        >>

        In my work with embedded software, including safety critical systems, I
        found that I wanted 2 modes of behavior on an assert failure:

        1. In development
        It was appropriate to have the system just halt so we could look at
        the call stack to see which of our assumptions failed and why.

        2. In production
        Here, we had to be certain that a system halt would not be worse than
        trying to continue despite the failed assertion. So the team defined
        severity levels and associated one with each assertion in the code. Then
        a wrapper around the assert function would check its severity code and
        decide whether to really halt, whether to issue a warning, or just push
        on silently.

        This worked beautifully for us and we achieved one of the lowest bug
        rates I have ever seen - 0.2 bugs per function point.

        In addition we had a very simple trouble log always enabled. When any
        assert fired - whether there was a halt or not - we dropped a short
        diagnostic text message into a buffer, and this gave us a clue to what
        was happening if we had to diagnose strange behavior. Conceptually, it
        was very much like the "black box" recorder used in airplanes that just
        records the most recent 30 minutes or so of activity.

        - njv

        --
        ----------------------------------------------------------------------
        Nancy Van Schooenderwoert Leading edge Agile coaching
        Specialties: Embedded systems and Enterprise-wide lean agile methods
        http://www.leanagilepartners.com
      Your message has been successfully submitted and would be delivered to recipients shortly.