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

Re: [XP] Pattern Encoded Suffix

Expand Messages
  • RonJeffries
    Marvin, ... I suggest you read Kent Beck s books on coding and naming patterns. Class names are generally nouns. In English, we modify nouns with adjectives
    Message 1 of 191 , Aug 9, 2012
    • 0 Attachment
      Marvin,

      On Aug 9, 2012, at 7:32 AM, "MarvinToll.com" <MarvinToll@...> wrote:

      > I've put together some thoughts on using a Pattern Encoded suffix when naming classes.
      >
      > Would appreciate any feedback.

      I suggest you read Kent Beck's books on coding and naming patterns.

      Class names are generally nouns. In English, we modify nouns with adjectives that go to the left of the noun.

      So we might have classes like Button, RoundedButton, BigFlashyRoundedButton.

      The most important thing about all these is that they are Buttons. The English reader realizes that automatically because Button is the last thing in the string.

      The pattern is the least interesting thing about an object, I should think. A suffix will appear to be the most important thing.

      In my opinion, a pattern indicator has no place in a name at all. When we want to know how something is built, we look at its implementation, which is one click away in any reasonable IDE.

      Ron Jeffries
      www.XProgramming.com
      Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell



      [Non-text portions of this message have been removed]
    • MarvinToll.com
      Jeff, Thanks for your feedback. The notion that a a Java author precisely considers whether they are using one of the two exception mechanisms to indicate a
      Message 191 of 191 , Sep 23, 2012
      • 0 Attachment
        Jeff,

        Thanks for your feedback.

        The notion that a a Java author precisely considers whether they are using one of the two exception mechanisms to indicate a true unanticipated exceptional break-down, or as an indication of alternate path processing (e.g. instead of return codes), is the thought-path I'm suggesting for consideration.

        As you mentioned (twice), there are contexts where the author could be wrong... and the code catching can respond as required.

        Said another way, I'm suggesting that authors throwing exceptions clarify the intended usage... even though a client's corner-case might warrant a different course than the author anticipated.

        _Marvin
        PatternEnabled.com

        --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
        >
        > The code that throws an exception should not (and cannot reasonably) know how the code that catches it will handle it. It's the responsibility of the code that catches the exception to do the right thing.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.