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

How To Make Your Java Code Understandable

Expand Messages
  • Abder-Rahman
    Simply follow this link to view the article: http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
    Message 1 of 4 , Apr 1, 2010
    • 0 Attachment
    • strazhce
      Hi, ... ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think... We have a codebase, where we use named constants.
      Message 2 of 4 , Apr 4, 2010
      • 0 Attachment
        Hi,

        --- In extremeprogramming@yahoogroups.com, "Abder-Rahman" <abderrahmanali@...> wrote:
        >
        > Simply follow this link to view the article: http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
        >
        ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think...

        We have a codebase, where we use named constants. E.g.:
        class InsuranceConstants{
        final static int INSURANCE_OF_CAR;
        }
        Note the type "int".

        I wonder:
        1. Is there any substantial value to using more specific type? E.g.:
        ...
        final static EInsurance INSURANCE_OF_CAR
        ...
        2. If you have an existing code using "int" approach, what would you do when adding some new features, some new enumerations:
        a] stick to the int approach
        b] mix - use specific types (see 1) for new features, leave ints where they already are
        c] refactor existing ints (replace type code with class refactoring) - BUT: this may need substantial effort, so only a] or b] may be viable

        Thanks for your opinion/ideas.

        Oleg
      • Curtis Cooley
        Primitive obsession is bad. Whenever you have a value that has a meaning, I strongly encourage you to consider making it an object. Often, once you have the
        Message 3 of 4 , Apr 4, 2010
        • 0 Attachment
          Primitive obsession is bad. Whenever you have a value that has a meaning, I
          strongly encourage you to consider making it an object. Often, once you have
          the object, it attracts behavior. If the object doesn't start to hold it's
          own weight, you can get rid of it.

          Beware that constants and enums often lead to
          http://ponderingobjectorienteddesign.blogspot.com/2008/09/if-bugs.html which
          is why I like to make objects. Easier to convert to polymorphism if you
          already have the object.

          On Sun, Apr 4, 2010 at 9:28 AM, strazhce <infobox.oleg@...> wrote:

          >
          >
          > Hi,
          >
          >
          > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
          > "Abder-Rahman" <abderrahmanali@...> wrote:
          > >
          > > Simply follow this link to view the article:
          > http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
          > >
          > ok, this is a basic principle - no magic numbers. Not new, but very
          > important. This made me think...
          >
          > We have a codebase, where we use named constants. E.g.:
          > class InsuranceConstants{
          > final static int INSURANCE_OF_CAR;
          > }
          > Note the type "int".
          >
          > I wonder:
          > 1. Is there any substantial value to using more specific type? E.g.:
          > ...
          > final static EInsurance INSURANCE_OF_CAR
          > ...
          > 2. If you have an existing code using "int" approach, what would you do
          > when adding some new features, some new enumerations:
          > a] stick to the int approach
          > b] mix - use specific types (see 1) for new features, leave ints where they
          > already are
          > c] refactor existing ints (replace type code with class refactoring) - BUT:
          > this may need substantial effort, so only a] or b] may be viable
          >
          > Thanks for your opinion/ideas.
          >
          > Oleg
          >
          >
          >



          --
          Curtis Cooley
          curtis.cooley@...
          home:http://curtiscooley.com
          blog:http://ponderingobjectorienteddesign.blogspot.com
          ===============
          Leadership is a potent combination of strategy and character. But if you
          must be without one, be without the strategy.
          -- H. Norman Schwarzkopf


          [Non-text portions of this message have been removed]
        • extremeprogrammer
          Hi. There are many reasons that yield substantial value: 1. It s an enumerated value 2. It s not an arbitrary integer 3. It helps the code to document itself
          Message 4 of 4 , Apr 5, 2010
          • 0 Attachment
            Hi.

            There are many reasons that yield substantial value:

            1. It's an enumerated value
            2. It's not an arbitrary integer
            3. It helps the code to document itself
            4. It prevents certain kinds of programming errors (the fundamental purpose of a type system) by not throwing away type safety
            5. It helps you to add new values to the enumeration
            6. There is almost certainly some conditional logic related to the enumeration. As Curtis has already pointed out, when you Make It An Object (I'm sure this used to be a page on the Mother Wiki, but I can't find it any more), it tends to attract behaviour which can then be handled polymorphically.

            I actually wrote a rather angry blog about this a while ago: http://www.stateofflow.com/journal/62/anti-social-enumerations

            When adding new values to the enumeration, I would most likely take it as an opportunity to replace the integers with enums, primarily to provide type safety, but also as a first step towards redistributing the system intelligence. Since you are most likely going to need to inspect every use of the constants you have in order to determine if the new values need to be considered, changing the type (from int to enum) means that the compiler will tell you where the uses are, and most uses can potentially be fixed by changing the word 'int' to <the name of your enum>. This may result in a bigger checkin that you would have had otherwise, but your codebase will be the better for it.

            Regards,

            Lance


            --- In extremeprogramming@yahoogroups.com, "strazhce" <infobox.oleg@...> wrote:
            >
            > Hi,
            >
            > --- In extremeprogramming@yahoogroups.com, "Abder-Rahman" <abderrahmanali@> wrote:
            > >
            > > Simply follow this link to view the article: http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
            > >
            > ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think...
            >
            > We have a codebase, where we use named constants. E.g.:
            > class InsuranceConstants{
            > final static int INSURANCE_OF_CAR;
            > }
            > Note the type "int".
            >
            > I wonder:
            > 1. Is there any substantial value to using more specific type? E.g.:
            > ...
            > final static EInsurance INSURANCE_OF_CAR
            > ...
            > 2. If you have an existing code using "int" approach, what would you do when adding some new features, some new enumerations:
            > a] stick to the int approach
            > b] mix - use specific types (see 1) for new features, leave ints where they already are
            > c] refactor existing ints (replace type code with class refactoring) - BUT: this may need substantial effort, so only a] or b] may be viable
            >
            > Thanks for your opinion/ideas.
            >
            > Oleg
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.