Results tagged “Readability”

At work I regularly stumble across a specific type of processing: sorting a collection/list and afterwards only retrieving the first or last element. Such code constructs are clearly for fetching the minimum or maximum element but sorting the whole collection for just a single item seems to be a bit of overhead. And indeed it is and the Collection class provides methods for these purposes without having to juggle items in memory and creating new collection objects which are never really required.


Advice

If you have a collection and want to retrieve the minimum or maximum element from it you don't have to sort it and retrieve the first or last but java.util.Collections offers its min() and max() methods for that which are much more efficient for that exact purpose. These can also be used with custom Comparators.

Code-Example

Before

// retrieve smallest element
Collections.sort(elementList);
Element smallest = elementList.get(0);    
...
// fetch item with highest custom value
Collections.sort(customItemsList, Collections.reverseOrder(new MyCustomComparator()));
Item largestItem = customItemsList.get(0);

After

Element smallest = Collections.min(elementList);    
...    
Item largestItem = Collections.max(customItemsList, new MyCustomComparator());

Benefit

Readability gain. Possible huge performance gain, as min()/max() run in O(n) while sorting takes O(n log(n)).

Remarks

If the comparison methods (compare(), equals()) do not fulfill the Comparator requirements according to the Java SDK (see here) (i.e. A.equals(B) != B.equals(A) or (A<B)!=(B>A), etc.) then the result of min()/max() may be different than the result from the approach using sorted collections.

|

A few days ago I hit a problem while refactoring some legacy Java Code. Following my own advice to use safe and simpler library methods I changed the code-block

List<String> list = dao.getEntries(id);
if(list != null && list.size() > 1) {
  doFancyLogic(list);
}

to

List<String> list = dao.getEntries(id);
if(CollectionUtils.size(list) > 1) {
  doFancyLogic(list);
}

Should do the same, looks nicer and should be safer too, right? Imagine my confusion when suddenly several unit tests began failing at other parts of the code not directly related to this change. When I found out that this single line was the cause of the other errors I of course looked up the JavaDoc for CollectionUtils on Google. According to the docs at http://commons.apache.org/collections/apidocs/org/apache/commons/collections/CollectionUtils.html the size() method should return 0 when presented with a null collection. Things were very strange here. In fact, it took me a few days to find out what's wrong.

In fact, I did not recognize that the access to the JavaDoc was redirected to https://commons.apache.org/proper/commons-collections//apidocs/org/apache/commons/collections/CollectionUtils.html, which did not show the documentation of the latest stable CollectionUtils docs (as it did until a few weeks ago) but showed the version of the SVN tip. It took a roundtrip through the Apache Commons main page to find the correct JavaDoc page for the current stable 3.2.1 CollectionUtils at https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections/CollectionUtils.html. And, surprise surprise, there the API for the size() method looks a bit different: "Throws: java.lang.IllegalArgumentException - thrown if object is not recognised or null".
Well, so much for the praised null-safety of Apache Commons... In the current implementation, CollectionUtils.size() is of no use for me and I reverted the refactoring.

In the end I was a victim of partly my own assumptions for the null-safety of Apache Commons and partly a very weird redirection of the Google search result URL. I still have no idea why this URL suddenly gets redirected to a different version than it did until a few weeks ago but I hope that either Google soon updates its search result (unlikely as there are loads of references to this address) or Apache corrects it to its former destination. For the safety of users in my opinion the correct version which shows up should be the one of the latest stable version, not an arbitrary SVN version.

Lesson learned: also check version of JavaDoc if something smells fishy, even if it has been correct in the past.

|

Another quick addition to my Java Tips series. This instance deals again with adding some safety while reducing a bit of code clutter.


Advice

Use Commons ObjectUtils.toString() instead of directly calling toString() on an object if it may be null. This also allows for a alternate result if the object is null.

Code-Example

Before

final String projectId = (request.getParameter("projectid") != null) ? request.getParameter("projectid").toString() : "";
final String roleId = (request.getParameter("roleid") != null) ? request.getParameter("roleid")
        .toString() : "DEFAULT";

After

final String projectId = ObjectUtils.toString(request.getParameter("projectid"));
final String roleId = ObjectUtils.toString(request.getParameter("roleid"), "DEFAULT");

Benefit

Readability gain. Safety gain, as ObjectUtils methods are null-safe. The reduced code footprint eases recognition of the intention, which is even more significant if there should be a default text if the object instance is indeed null.

Remarks

None.

|

Another quick-shot Java Tip. Keeping it simple because I don't have much time currently. It's one of the lesser-known facts of the instanceof-operator and I've seen it's applicability in some sources but YMMV.


Advice

Use the Java operator instanceof for implicit null-checks. Sometimes there is the need to check for both (eg. in equals()-methods), non-null and a certain class. Instead of checking for each condition seperately one can use just the instanceof operator, which handles a null-pointer in the same manner as a non-matching class.

Code-Example

Before

...
if (field != null) {
    if (field instanceof SomeClass) {
        ...
    }
}
...

After

...
if (field instanceof SomeClass) {
    ...
}
...

Benefit

Small readability gain.

Remarks

This seems to be one of the lesser known facts about Java there can be a small confusion with other participants on the same code who interpret this to an aparently missing null-check. But this comes as no danger when the other person just re-adds the null-check, there should be no bad effect on the logic. Maybe just spread this knowledge to your participants somehow ;)

| | Comments (1)

After quite some time this is another instance of the Java Tips. It's an addition to the Apache Commons related framework tips which are guiding into the direction that as a developer you should take advantage of existing and proven frameworks and know their features to leverage your development efficiency. This time complexity of the given example is a bit higher than in the previous tips.


Advice

Use Apache CollectionUtils for evaluation and manipulation of Collections.

Code-Example

A short spoiler for the following code: This is a routine which checks a given set of categories against a set of category-permissions for a user. The result is a set of categories, which the user is allowed to access.

Before

...
public boolean hasPermissionsToAccessCategory(String category) {
    return (this.permissions != null && this.permissions.contains(category));
}
...

...
public Set<String> getCategoriesAllowedToViewBySearchFilter() {
    Set<String> result = null;
    if ((this.filter != null && this.filter.getCategory() != null) && (!this.filter.getCategory().isEmpty())) {
        result = new HashSet<String>();
        for (String category : this.filter.getCategory()) {
            if (this.hasPermissionsToAccessCategory(category)) {
                result.add(category.toString());
            }
        }
        if(result.size() == 0) {
            result = null;
        }
    } else {
        result = this.getAllCategories();
    }

    return result;
}
....

After

...         
public Set<String> getCategoriesAllowedToViewBySearchFilter() {
    Set<String> result = null;
    if (this.filter != null &&
        this.permissions != null &&
        CollectionUtils.isNotEmpty(this.filter.getCategory())) {

        // get only categories, which are both in permissions and filter categories
        result = new HashSet<String>(CollectionUtils.intersection(this.permissions, this.filter.getCategory()));

        // if no results, return null
        if(result.isEmpty()) {
            result = null;
        }
    } else {
        result = this.getAllCategories();
    }

    return result;
}
...

Benefit

Huge readability gain and a safety gain. The code and intention is much clearer here and also has a smaller footprint. The maintainability has been raised because for a developer not familiar with the routine it needs a bit of brainpower to find out what the initial code really does. The removal of the additional method and usage of CollectionUtils.intersection() makes it much easier to understand, how the two sets are compared to each other to retrieve the correct results.

Remarks

None if you are initially writing similar logic. If you're refactoring a method which seems to be better off with framework-provided functionality be careful and think over it a second time. Re-evaluate the code until you're really sure because it's easy to overlook a small detail which changes the results for a certain special case.

|

And we're continuing with our next Java Tip. Back on using frameworks for our convenience, I present another often useful possibility to let the StringUtils handle lots of work for you.


Advice

Use Apache StringUtils for concatenating Strings from Arrays or Lists, also when you need to delimit them with an arbitrary string.

Code-Example

Before

...
SQL_WHERE += " AND V.cat_display_name IN (";
boolean addComma = false;
for (String category : filter.getCategories()) {
  if (addComma) {
    SQL_WHERE += ", ";
  }
  SQL_WHERE += "'" + category + "'";
  addComma = true;
}
SQL_WHERE += ") ";
...

...
String SQL = "";
for(String category: filter.getCategories()) {
    SQL += val + ", ";
}
SQL = SQL.substring(0, SQL.length()-2);
....

After

...         
SQL_WHERE += " AND V.cat_display_name IN (";
SQL_WHERE += "'" + StringUtils.join(filter.getCategories(), "', '") + "'";
SQL_WHERE += ") ";
...

Benefit

Huge readability gain and a safety gain. The code and intention is much clearer and the possibility to hide bugs in the loop-logic (which I have seen often) is not present. Also, depending on the length of the Array or List, it may also present a small performance gain (see Java Tip #2) but that's in most such cases neglibigle.

Remarks

None.

|

The Java Tips series gets another entry, yay! I'll keep within the plain Java language this time, no frameworks or other fancy tricks, just basic Java know-how.


Advice

Use Java5's for-each loop instead of manually iterating over arrays or collections whenever it is possible.

Code-Example

Before

...
// access using index
for (int i = 0; i < offerList.getMembers().size(); i++) {
    CustomizedOfferOverviewDTO dto = (CustomizedOfferOverviewDTO)offerList.getMembers().get(i);
...
}
...
// access using iterator
Iterator iter = m_elements.iterator();
while (iter.hasNext()) {
    ILoadable loadable = (ILoadable)iter.next();
...
}
...

After

...
for(CustomizedOfferOverviewDTO dto : offerList.getMembers()) {
...
}
...
for(ILoadable loadable : m_elements) {
...
}
...

Benefit

Readability gain. The for-each makes it a lot easier to iterate over collections and arrays and to read and recognize the code. Furthermore the Java compiler might also be able to optimize the loop a bit better internally but in general this improvement is beyond measuring accuracy and therefore is not an argument in this case.

Remarks

This only works as long as it's not modifying the collection or array beneath it. If deleting or replacing elements, you have to use the previous-style looping again where you have direct access to the Iterator.

|

Tip #5 in my Java Tips series is again focussing around the Apache Commons framework. In the same manner the StringUtils simplifies many common operations on Strings (see also Java Tip #3), DateUtils ease some of the pain when working with Java Date objects.


Advice

Use Commons DateUtils to manipulate and calculate dates.

Code-Example

Before

...
private static Date add(Date date, int field, int amount) {
    Calendar cal = Calendar.getInstance();
    cal.setTime(date);
    cal.add(field, amount);
    return cal.getTime();
}
...
public static Date getNextDay() {
    return add(getCurrentDay(), Calendar.DATE, 1);
}
...

After

...
public static Date getNextDay() {
    return DateUtils.addDays(getCurrentDay(), 1);
}
...

Benefit

Huge readability gain. By using DateUtils for calculating and manipulating Dates the code footprint gets smaller and easier to read. Furthermore by using explicit methods like addDays() it is clearer which part of a date is to be modified, compared to the partly ambiguous constants in the Calendar class. DateUtils also contains methods to round or truncate Dates to certain parts of the date, eg. truncate() by Calendar.HOUR sets minutes, seconds and miliseconds to zero.

Remarks

None.

|

The next tip in my series of Java Tips deals with the usage of Java frameworks. Some people still have a certain hatred against Java frameworks because many of them have been not easy to deal with in in their past. Nevertheless, while those have either disappeared or evolved in a more usable shape, there have always been some frameworks which were rock-solid and widely accepted as simple and extremely useful. One of those is the Lang package in the library collection of the Apache Commons. In my opinion this one is a must-have for almost every Java project or application. Use it. Period.


Advice

Use Commons StringUtils for checking Strings content for null, emptiness or blankness.

Code-Example

Before

if(str != null && !str.equals("")) { ... }
if(str != null && !str.trim().equals("")) { ... }
if("".equals(str)) { ... }
if(str == null || "".equals(str.trim())) { ... }

After

if(StringUtils.isNotEmpty(str)) { ... }
if(StringUtils.isNotBlank(str)) { ... }
if(StringUtils.isEmpty(str)) { ... }
if(StringUtils.isBlank(str)) { ... }

Benefit

Huge readability gain. Safety gain, as StringUtils methods are null-safe. By using the provided utility methods from StringUtils the intent of a condition is much easier and faster to recognize. Furthermore, since all methods of StringUtils are able to correctly process null Strings, there is no danger of an unexpected NullPointerException anymore because of a forgotten null-check.

Remarks

None.

|

1

Archives