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

[OT] Appeal to save the comments inside the code

Expand Messages
  • Marco Bizzarri
    I ve hunted a bug for a few months; the bug, in the end, was caused by a method cacheGC which was called in the middle of a transaction, which could cause
    Message 1 of 49 , Sep 19, 2008
      I've hunted a bug for a few months; the bug, in the end, was caused by
      a method "cacheGC" which was called in the middle of a transaction,
      which could cause havoc.

      After discovering the bug, I looked at the code; just above the method
      definition, I found the following comment:

      # TODO: we should test what happens when cacheGC is called mid-transaction.

      This caused me the feeling that I should immediately make an appeal in
      order to avoid the "exctinction" of the comments.

      Indeed, I think comments are a form of (humouristic) literature, which
      should be preserved.

      Regards
      Marco
      --
      Marco Bizzarri
      http://notenotturne.blogspot.com/
      http://iliveinpisa.blogspot.com/
    • 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
        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.