Style: order of fields, params and methods

Discussion in 'Java' started by Karsten Wutzke, Aug 15, 2007.

  1. Hello!

    When programming I keep switching the order of declared fields, method
    params (especially for constructors) and sometimes methods themselves
    in the class.

    -> Is there a specific order recommended? <-

    For constructors:

    Mostly I keep ordering them in "most mandatory order first". I put
    those in the param list first, probably coming off some PHP coding
    where you can omit passing optional method params at the end:

    function do_something($param1, $param2, $param3, $param4 = null,
    $param5 = "black")
    {
    ....
    }

    => Calling do_something(1, "dfgdf", 0); is perfectly valid.

    Is it better to keep "mandatory order first", use "order by topic",
    e.g. group somewhat related params whether mandatory or optional. Or
    another?

    Karsten
     
    Karsten Wutzke, Aug 15, 2007
    #1
    1. Advertisements

  2. Karsten Wutzke

    GArlington Guest

    Declared fields and methods:
    group by access rights from public to private (alphabetical order
    maybe for ease of finding them later).

    In java you have to declare each method for any number and types of
    params you may want to use, i.e.
    myMethod(String param1, Object param2, int param3){
    .... common processing here ...
    }
    myMethod(String param1, Object param2){
    myMethod(param1, param2, defaultValueForParam3)
    }
    myMethod(String param1){
    myMethod(param1, defaultValueForParam2)
    }
     
    GArlington, Aug 15, 2007
    #2
    1. Advertisements

  3. For parameters, I prefer to put the most optional ones at the end,
    because I may want to do multiple constructors or methods, turning them
    into optional parameters.

    void doSomething(int param1, int param2, int param3, Object param4,
    String param5){
    ....
    }

    void doSomething(int param1, int param2, int param3, Object param4){
    doSomething(param1, param2, param3, parm4, "black");
    }
    void doSomething(int param1, int param2, int param3){
    doSomething(param1, param2, param3, null);
    }

    Even if, initially, I'm only doing the first version, putting the
    potentially optional parameters last leaves the door open to making them
    optional later.

    I tend to group data logically, because I use Eclipse a lot and its
    package explorer lists alphabetically.

    Patricia
     
    Patricia Shanahan, Aug 15, 2007
    #3
  4. Karsten Wutzke

    Daniel Pitts Guest

    I find that if I think I might want to re-order, add, or remove
    parameters from a constructor or function that has a large number of
    parameters already, I choose to use the Parameter Object, and have it
    usually fulfill the Builder pattern as well.

    class SomethingParams {
    private String param;
    private String blah;

    public SomethingParams setParam(String value) {
    param = value;
    return this;
    }

    public SomethingParams setBlah(String blah) {
    this.blah = blah;
    return this;
    }
    }


    doSomething(new SomethingParams().setBlah("My blah is better than your
    blah").setParam(null));

    You should also add a validation check (either as a method on
    SomethingParams, or in doSomething) that throws an
    IllegalArgumentException or some such, if the manditory arguments
    aren't correctly set.


    Also, at this point, you might consider whether or not doSomething
    actually belongs in SomethingParams, and if SomethingParams can be
    made to be more self contained.

    Or, if you would pass this Param object into a constructor, use the
    Factory pattern instead, and have a SomethingBuilder.newSomething(),
    which calls the appropriate constructor for the client, based on the
    other configuration they've done.
     
    Daniel Pitts, Aug 15, 2007
    #4
  5. I know. The PHP thing was just the general motivation of my question -
    to maybe emphasize/promote "mandatory first order".

    i.e.
    snipped

    Karsten
     
    Karsten Wutzke, Aug 15, 2007
    #5
  6. Karsten Wutzke

    Adam Maass Guest

    Eh. This is entirely stylistic, and up to each to determine.

    Generally, I order the members of a class like this:


    Constants (IE, static final fields)

    Static variables (static, non-final fields)

    Instance variables

    Constructors (Generally fewer parameters to the complete list of parameters.
    Generally, all constructors end up resolving to one in this class.)

    Instance methods. (If I worry about order at all within this grouping, it
    generally is by "topic." A grouping by topic tends to suggest an opportunity
    for another class if you're into aggressive refactoring.)

    Static methods, except "main."

    Instance member classes

    Static member classes

    main method.
     
    Adam Maass, Aug 15, 2007
    #6
  7. Karsten Wutzke

    Oliver Wong Guest

    As far as I know, there's no standard (defacto or otherwise) for the
    order of class members. If your programming group has a specific standard,
    follow that one. Otherwise, do whatever you want?

    Personally, I don't really care how my coworkers order the members,
    because my IDE can present a sorted view of them without actually
    manipulating them on the disk, so I see them in the order that I want to
    see them.

    - Oliver
     
    Oliver Wong, Aug 15, 2007
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.