Reducing conditional statements to avoid cyclomatic complexity

Use Collection.contains.

That reduces your if statement to the following:

if ( filterCarCodes.contains(auto.getCarCode()) ){
    //stuff
}

You can initialize the Collection once with Arrays.asList. Then declare it as a static final class variable and you're pretty much set. An alternative is the HashSet you described - via Arrays.asList you'd have a filled Collection, which is one of the constructors for a HashSet with contents: HashSet(Collection<? extends E> c). You'll pay for the double conversion, but it should be faster than directly using a List.

Look at the algorithm: the codes work as a set, so use a set.

Your program is then clearer, shorter, and less prone to error. For example, you've inadvertantly (I assume) repeated the first code: harder to do if the codes are all lined up ready to be marched into a set constructor.

You have also repeatedly evaluated auto.getCarCode(). The performance hit is no doubt trivial, but you have added a lot of superfluous tokens for the human eye to scan. And how do you make all these condition lines? You copy the first one, and paste, paste, paste. Enough said.

I'm worried that this set of codes is to be burned into the program. It should surely be read in from a configuration file. Is changing the set of codes a program change, with all the testing that entails? I hope not.

Follow Through with the Object Oriented Answers

Some of the answers I've read call for a collection, and implementing a collection is exactly the right object oriented answer. BUT it's not the right kind of collection.

I humbly suggest a class as shown below.

• The autoCode is defined - that's how I see things - by virtue of containment in a class with business domain meaning. "FAQ025" is just a string. AutoDto.autoCode is an Auto Code.

• A generic collection of generic strings falls short. It means nothing. Well, it does mean clients will be forever transforming strings to string collections to AutoCode objects and back again.

• Consistency. Ease of Maintenance.

  • string structures are forced to AutoCode objects in the constructors.
  • Now all we have to code for is AutoCode objects.
  • Up-front input validation; avoid the "could be null, could be empty" string quandary. We don't blow up just because a reference is null or a string is empty.

• Single Responsibility Principle.

  • The task at hand is a natural fit for a collection iteration. And GetAutoCode() is in the right class, not a "utility" method floating around in CodeBase Land somewhere.
  • AutoCode knows what it's equal to. The client does not have to know AutoCode implementation details and does not need to know how to test for equality.

• Re-usability. With the GetAutoCode method in the proper class it is by design re-useable.

• DRY, Don't Repeat Yourself. Without the class encapsulation we force every client to replicate the data setup.

• Decouple from client code (optional)

  • If the AutoCode values are coming to you in some odd-ball structure write a separate class that plucks out the particulars and passes it to AutoCodeCollection constructors in the expected form.
  • IMHO it's a judgement call; not really needed unless the odd-ball structure is really complex and we have several classes of this nature.

Warning this is C#, but you get the idea

public class AutoDto : List<AutoDto> {
    public AutoDto (string aCode) {
        this.autoCode = aCode?? string.Empty; // if aCode is null, use string.Empty;
    }

    protected string autoCode;
    public string GetAutoCode() { return this.autoCode; }

    public override bool Equals (object other) {
        if (other == null) return false;
        if(!other is AutoCode) return false;
        if(this.autoCode == other.autoCode) return true;
        return false;
    }
}

public class AutoDtoCollection : List<AutoDto> {
    public AutoDtoCollection(HashTable autoCodeValues) {}
    public AutoDtoCollection(List<string> autoCodeValues) {}

    // if you must accept a string
    public bool Contains (string testCode) {
        if (string.IsNullOrWhitespace(testCode)) return false;
        AutoCode tempObject = null;

        // don't implement AutoCode.Equals a second time
        // by violating SRP and making this collection class
        // to the equal-izing.
        foreach (AutoCode mycode in this) {
            tempObject = new AutoCode(testCode);
            if ( mycode.Equals(testCode)) return true;
        }

        return false;
    }

    public override bool Contains (object other) {
        if (other == null) return false;

        if (! other is AutoDto) return false;

        // we overrode Equals so we're comparing on the autocode property
        if (this.Contains(other))  return true; 

        return false;
    }

    public override bool Add(string aCode) {
        if(string.IsNullOrWhiteSpace(aCode)) return false;
        if(this.Add(new AutoCode(aCode))  // allows duplicates
            return true;
        else
            return false;
    }

}

public class AutoCodeCollectionFactory {
    public AutoCodeCollection Create (HashTable theCodz) {
        foreach (var thing in theCodez {
            // property extraction sound effects here
         }
    }

    public AutoCodeCollection Create (SomeCustomeClass theCodz) {
       // more fussing about to extract what we need
    }
}

I would do it like this.

private List<AutoDto> getFilteredAutoList(Collection<String> carCodes) 
{
        List<AutoDto> autoList = getAutoListForCoverage();
        List<AutoDto> filteredAutoList = new ArrayList<AutoDto>();
        for (AutoDto auto : autoList)
        {
            if (carCodes.contains(auto.getCarCode()))
            {
                 filteredAutoList.add(auto);
            }           
        }
        return filteredAutoList;
}

You can pass whatever collection of car codes you want to the filtering function. Use a simple list, unless you can run benchmarks to prove filtering with a list is a bottleneck to your application.

Follow Through with the Object Oriented Answers

Some of the answers I've read call for a collection, and implementing a collection is exactly the right object oriented answer. BUT it's not the right kind of collection.

I humbly suggest a class as shown below.

• The autoCode is defined - that's how I see things - by virtue of containment in a class with business domain meaning. "FAQ025" is just a string. AutoDto.autoCode is an Auto Code.

• A generic collection of generic strings falls short. It means nothing. Well, it does mean clients will be forever transforming strings to string collections to AutoCode objects and back again.

• Consistency. Ease of Maintenance.

  • string structures are forced to AutoCode objects in the constructors.
  • Now all we have to code for is AutoCode objects.
  • Up-front input validation; avoid the "could be null, could be empty" string quandary. We don't blow up just because a reference is null or a string is empty.

• Single Responsibility Principle.

  • The task at hand is a natural fit for a collection iteration. And GetAutoCode() is in the right class, not a "utility" method floating around in CodeBase Land somewhere.
  • AutoCode knows what it's equal to. The client does not have to know AutoCode implementation details and does not need to know how to test for equality.

• Re-usability. With the GetAutoCode method in the proper class it is by design re-useable.

• DRY, Don't Repeat Yourself. Without the class encapsulation we force every client to replicate the data setup.

Warning this is C#, but you get the idea

public class AutoDto : List<AutoDto> {
    public AutoDto (string aCode) {
        this.autoCode = aCode?? string.Empty; // if aCode is null, use string.Empty;
    }

    protected string autoCode;
    public string GetAutoCode() { return this.autoCode; }

    public override bool Equals (object other) {
        if (other == null) return false;
        if(!other is AutoCode) return false;
        if(this.autoCode == other.autoCode) return true;
        return false;
    }
}

public class AutoDtoCollection : List<AutoDto> {
    public AutoDtoCollection(HashTable autoCodeValues) {}
    public AutoDtoCollection(List<string> autoCodeValues) {}

    // if you must accept a string
    public bool Contains (string testCode) {
        if (string.IsNullOrWhitespace(testCode)) return false;
        AutoCode tempObject = null;

        // don't implement AutoCode.Equals a second time
        // by violating SRP and making this collection class
        // to the equal-izing.
        foreach (AutoCode mycode in this) {
            tempObject = new AutoCode(testCode);
            if ( mycode.Equals(testCode)) return true;
        }

        return false;
    }

    public bool Contains (object other) {
        if (other == null) return false;

        if (! other is AutoDto) return false;

        // we overrode Equals so we're comparing on the autocode property
        if (this.Contains(other))  return true; 

        return false;
    }

    public bool Add(string aCode) {
        if(string.IsNullOrWhiteSpace(aCode)) return false;

        if(this.Add(new AutoCode(aCode))
            return true;
        else
            return false;
    }

}