Which is a better pattern (coding style) for validating arguments - hurdle (barrier) or fence? [duplicate]

I don't know if there are any accepted names for these patterns (or anti-patterns), but I like to call them what I call them here. Actually, that would be Question 1: What are accepted names for these patterns, if any? Suppose there is a method that accepts a bunch of parameters, and you need to check for invalid input before executing actual method code: public static void myMethod (String param1, String param2, String param3) Hurdle Style (guard clause, early return) I call it so because it's like hurdles a track runner has to jump over to get to the finish line. You can also think of them as conditional barriers. { if (param1 == null || param1.equals("")) { // some logging if necessary return; // or throw some Exception or change to a default value } if (param2 == null || param2.equals("")) { // I'll leave the comments out return; } if (param3 == null || param3.equals("")) { return; } // actual method code goes here. } When the checks are for a certain small section in a larger method (and the section cannot be moved to a smaller private method), labelled blocks with break statements can be used: { // method code before block myLabel: { if (param1 ... // I'll leave out the rest for brevity break myLabel; if (param2 ... break myLabel; ... // code working on valid input goes here } // 'break myLabel' will exit here // method code after block } Fence Style (single exit) This surrounds the code with a fence that has a conditional gate that must be opened before the code can be accessed. Nested fences would mean more gates to reach the code (like a Russian doll). { if (param1 != null && !param1.equals("")) { if (param2 != null && !param2.equals("")) { if (param3 != null && !param3.equals("")) { // actual method code goes here. } else { // some logging here } } else { // some logging here } } else { // some logging here } } It could be re-written as follows too. The logging statements are right beside the checks, rather than being after the actual method code. { if (param1 == null || param1.equals("")) { // some logging here } else if (param2 == null || param2.equals("")) { // some logging here } else if (param3 == null || param3.equals("")) { // some logging here } else { // actual method code goes here. } } Question 2: Which style is better, and why? Question 3: Are there any other styles? I personally prefer hurdle style because it looks easier on the eyes and does not keep indenting the code to the right every time there's a new parameter. It allows intermittent code between checks, and it's neat, but it's also a little difficult to maintain (several exit points). The first version of fence style quickly gets really ugly when adding parameters, but I suppose it's also easier to understand. While the second version is better, it can be broken accidentally by a future coder, and does not allow intermittent code between conditional checks.

Feb 4, 2025 - 11:43
 0
Which is a better pattern (coding style) for validating arguments - hurdle (barrier) or fence? [duplicate]

I don't know if there are any accepted names for these patterns (or anti-patterns), but I like to call them what I call them here. Actually, that would be Question 1: What are accepted names for these patterns, if any?

Suppose there is a method that accepts a bunch of parameters, and you need to check for invalid input before executing actual method code:

public static void myMethod (String param1, String param2, String param3)

Hurdle Style (guard clause, early return)

I call it so because it's like hurdles a track runner has to jump over to get to the finish line. You can also think of them as conditional barriers.

{
    if (param1 == null || param1.equals("")) {
        // some logging if necessary
        return; // or throw some Exception or change to a default value
    }

    if (param2 == null || param2.equals("")) {
        // I'll leave the comments out
        return;
    }

    if (param3 == null || param3.equals("")) {
        return;
    }

    // actual method code goes here.
}

When the checks are for a certain small section in a larger method (and the section cannot be moved to a smaller private method), labelled blocks with break statements can be used:

{
    // method code before block

    myLabel:
    {
        if (param1 ... // I'll leave out the rest for brevity
            break myLabel;
        if (param2 ...
            break myLabel;
        ...
        
        // code working on valid input goes here
    
    } // 'break myLabel' will exit here
    
    // method code after block
}

Fence Style (single exit)

This surrounds the code with a fence that has a conditional gate that must be opened before the code can be accessed. Nested fences would mean more gates to reach the code (like a Russian doll).

{
    if (param1 != null && !param1.equals("")) {
        if (param2 != null && !param2.equals("")) {
            if (param3 != null && !param3.equals("")) {
                
                // actual method code goes here.
                
            } else {
                // some logging here
            }
        } else {
            // some logging here
        }
    } else {
        // some logging here
    }
}

It could be re-written as follows too. The logging statements are right beside the checks, rather than being after the actual method code.

{
    if (param1 == null || param1.equals("")) {
        // some logging here
        
    } else if (param2 == null || param2.equals("")) {
        // some logging here
        
    } else if (param3 == null || param3.equals("")) {
        // some logging here
        
    } else {
        
        // actual method code goes here.
        
    }
}

Question 2: Which style is better, and why?

Question 3: Are there any other styles?

I personally prefer hurdle style because it looks easier on the eyes and does not keep indenting the code to the right every time there's a new parameter. It allows intermittent code between checks, and it's neat, but it's also a little difficult to maintain (several exit points).

The first version of fence style quickly gets really ugly when adding parameters, but I suppose it's also easier to understand. While the second version is better, it can be broken accidentally by a future coder, and does not allow intermittent code between conditional checks.