Enhancement suggestions for getter/setter/equals/hash code generator

[Eric Kintzer]

Scott - great stuff with the new code generator. The equals/hash stuff is especially welcomed. As I watched the video, I was immediately struck with two enhancement suggestions that I kindly offer

‌

1 - Generate the getters and setters each as one line. eg.

public Integer getIdNumber() {return idNumber;}
public void setName(String name) {this.name = name;}

why? this boilerplate code need not take up vertical real estate

2 - (User-option) Generate setters as fluent/builder pattern rather than individual methods, e.g.

public Individual withName(String val) {this.name = val; return this;}

why?

• when using, the .withXXX pattern allows for more readable code (IMHO) as one gets auto-indents

Individual individual = new Individual()
    .withName('foo')
    .withDoB(System.today())
    ... ;

versus

Individual individual = new Individual();
individual.setName('foo');
individual.setDob(System.today());

Note rough analog to

Account account = new Account(
    Name = 'foo',
    Website = 'http://foo.com',
    ...
    );

is nicer looking than

Account account = new Account();
account.name = 'foo';
account.Website = 'http://foo.com';
...        

‌

Note that generating a constructor with > 4 args runs into a PMD warning

[Scott Wells]

Great recommendations, Eric. Thanks! Generating as single-line should be quite simple. Someone else asked if I could optionally generate ApexDoc header comments, so I think both of those can fit into the next iteration.

The second request is interesting because the Java analog offers pretty much that option:

‌

The former option--Records style for getters--indicates that read methods should be named as foo() instead of getFoo(), and the latter option--Builder for setters--indicates that write methods should follow the builder/fluent pattern, returning this after setting the value.

Should be simple enough to add those enhancements as well. Not sure if they’ll fit into the next build along with the two above, but it seems like they should…

[Eric Kintzer]

Thanks Scott - I could tell you were proud of this feature by your tone on YouTube!

You could also consider adding an optional toJson() method - there are issues here as not every type is serializable but would work in most use cases

[Scott Wells]

Oh, regarding this:

Note that generating a constructor with > 4 args runs into a PMD warning

that’s all based on PMD Apex configuration:

   <rule ref="category/apex/design.xml/ExcessiveParameterList" message="Avoid long parameter lists">
      <priority>3</priority>
      <properties>
         <property name="minimum" value="4" />
      </properties>
   </rule>

Set that value to whatever makes sense for your projects (or disable the rule), but the default ruleset starts warning at 4 (which seems a bit low to me).

[Scott Wells]

Okay, these are all implemented except for record-style getters for fields:

‌

My take is that if you want record-style access to fields in Apex, you should probably be using properties anyway. We’ll see if others agree or disagree, but I’m not inclined to implement that until/unless I hear from folks that it would be used.

This should all be included in Thursday’s build.

[Scott Wells]

Delivered in 2.2.8.2.

[Eric Kintzer]

Nice! -- My next custom ApexType will try this for sure!