Good job. In general, we have a uutils module for utils that can serve other projects, not just engine (i.e - we can have a separate artifact that does not depend on common for example). IMHO, 2 is a good candidate to go to uutils.
Yair ----- Original Message ----- > From: "Mike Kolesnik" <[email protected]> > To: [email protected] > Sent: Sunday, July 13, 2014 9:15:06 PM > Subject: [ovirt-devel] Removing boilerplate code in engine > > Hi, > > I recently introduced 2 changes for removing boilerplate code: > > 1. http://gerrit.ovirt.org/29414 - Fluent syntax for writing validations > 2. http://gerrit.ovirt.org/29617 - Wrapper for locks to use with > try-with-resources > > By removing boilerplate code we're making the code less error prone and > easier to read (and maintain). > I've already sent some simple refactors to use these new styles of writing, > but more work is necessary to apply to the whole project. > > I urge all engine developers that need to write such code to use the new > styles of writing. > > Below are examples for each change. > > 1. When expecting a negative outcome, instead of using: > return getVds() == null > ? new > ValidationResult(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST) > : ValidationResult.VALID; > > use: > return > ValidationResult.failWith(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST) > .when(getVds() == null); > > > When expecting a positive outcome, instead of using: > return > FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version()) > ? ValidationResult.VALID > : new > > ValidationResult(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL); > > use: > return > > ValidationResult.failWith(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL) > > .unless(FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version())); > > > 2. To lock a block of code, instead of using [1]: > lock.lock(); > try { > // Thread safe code > } finally { > lock.unlock(); > } > > use: > try (AutoCloseableLock l = new AutoCloseableLock(lock)) { > // Thread safe code > } > > [1] This is best used with locks from java.util.concurrent.locks package. > For regular thread safe blocks it's best to use the standard synchronized > block. > > Regards, > Mike > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
