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

Re: [XP] Writing simple software - A Challenge!

Expand Messages
  • Ron Jeffries
    ... I would agree that if a method encounters an error, it can be a good idea to say something about it. But the rule I m suggesting is Eliminate Exceptions .
    Message 1 of 139 , Dec 1, 2002
      On Sunday, December 1, 2002, at 2:56:32 PM, Kyle Cordes wrote:

      > I find the second behaviour a pain to deal with. If I pass this thing a
      > filename, I except it to read that file. If it can't, it shouldn't
      > silently ignore my intention and let the problem slip past, it should
      > complain - I should get an exception that the file shouldn't be read.
      > I've found low-level code eating errors is a very common cause of
      > unreliable, unpredictable behavious in largers systems I work on.

      I would agree that if a method encounters an error, it can be a good
      idea to say something about it. But the rule I'm suggesting is
      "Eliminate Exceptions". The second method encounters no errors!

      Please note again that the second definition of the method does not
      consider non-text characters to be exceptional, and that it doesn't
      consider too many characters to be exceptional, and that it doesn't
      consider file names that don't exist to be exceptional. They are
      normal cases.

      The second method is, approximately: given a list of strings, return
      the first 32767 text characters from files whose names are represented
      in that list of strings.

      > My general guideline is that a method / object should do what I told it
      > it do, or fall on its sword trying.

      I would say that a method should do what it advertises and /never/
      fall on its sword. That might be a somewhat important distinction.

      Here the subject is simple design. I suspect that if we compare the
      code to implement the two methods, and the code to use them, we'll
      find a substantial difference in simplicity.

      Often we may find a need to do something more complex than the
      simplest thing. However, since complexity is the enemy of the finite
      brain -- and mine, albeit the size of a planet, is finite -- it's
      prudent to have a good handle on what patterns produce the simplest
      solutions. We can elaborate if we need to -- or just for the hell of
      it.

      Ron Jeffries
      www.XProgramming.com
      I'm giving the best advice I have. You get to decide whether it's true for you.
    • J. B. Rainsberger
      So said ericheikkila on 12/4/2002 -------------------- ... Often, i means something. Say what you mean; mean what you say. :) J. B. Rainsberger,
      Message 139 of 139 , Dec 7, 2002
        So said ericheikkila on 12/4/2002 --------------------

        >Single letter variables drive me nuts. ;)
        >I use 'index' instead of 'i' (or loop, or maybe count, depending on
        >the context).
        >As far as abbreviations go...if the entire team agrees, fine.
        >If someone on the team doesn't know that itr is the same as iterator,
        >just change it to iterator.
        >
        >Usually, I'll not abbrev ;)

        Often, "i" means something. Say what you mean; mean what you say. :)

        J. B. Rainsberger,
        President, Diaspar Software Services
        Let's write software that people understand.
        http://www.diasparsoftware.com/
        telephone: +1 416 791-8603
        All correspondence (c) 2002 Diaspar Software Services.
        If you want to use it, just ask; don't steal.
      Your message has been successfully submitted and would be delivered to recipients shortly.