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

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

Expand Messages
  • Chris Wheeler
    On Wed, Oct 1, 2008 at 2:43 PM, Ron Jeffries ... Well, no *major* questions. Maybe I wasn t clear in an earlier post, but I personally think the marking
    Message 1 of 49 , Oct 1, 2008
    • 0 Attachment
      On Wed, Oct 1, 2008 at 2:43 PM, Ron Jeffries
      <ronjeffries@...>wrote:

      >
      > If you actually manage to ship without important questions, I'd
      > still be interested in what marking technique you would recommend
      > for those who have not yet attained that level of perfection.
      >

      Well, no *major* questions. Maybe I wasn't clear in an earlier post, but I
      personally think the marking technique that works best is to have the
      compiler screaming about #TODO, or some other custom tag that a dev shop
      chooses.

      Chris.


      [Non-text portions of this message have been removed]
    • 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.