When is it okay to go against the Style Guide?

[Nick Singh]

I'm trying to apply the JavaRanch Style Guide to all my future coding but I'm having a problem understanding how to not use break in the code below. The other loops are pretty ugly in this scenario, and not using break to break out of the foreach loop is inefficient and might create faulty results.

    public int currentlyLoggedIn() {
        int returnVal = 2;
        for (String each : currentPageCache) {
            Matcher loggedOut = parseLine(each,"id=\"login\"");
             if (loggedOut != null) {
                 returnVal = 0;
                 break
             }
             Matcher loggedIn = parseLine(each, "Logout</a>");
             if (loggedIn != null) {
                 returnVal = 1;
                 break;
             }
          }
        return returnVal;
    }
    /*
     * This method checks whether the script is currently logged in.
     * currentPageCache is an ArrayList<String> containing the html source of the webpage
     * parseLine() returns a Matcher object if one string is a subset of the other
     * The existence of the Matcher is used to test whether the script is logged in or not
    */

[Campbell Ritchie]

It is never OK to go against the style guide, but it is OK to choose a different style guide.
When you get a job, you will (probably) be given a style guide by your employer, which you must adhere to. Now you are on the Ranch, you are permitted to choose any style guide.

The JavaRanch style guide follows structured programming, which was introduced in the late 1960s following two seminal papers by Böhm and Jacopini (Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules) and Dijkstra (Goto considered Harmful), eschewing break and continue. It is always possible to avoid break and continue, except after switch. Interestingly enough, object-oriented programming was also invented in the late 1960s.

Let’s have a look at your method.
Using ints as return values to denote type of login is very old-fashioned, the sort of thing that was cutting-edge in C in 1973! If you are using an int, it would denote how many people are logged in. I would have thought you create a LoggedIn enum with the different values representing whatever 0, 1, 2 represent in the current version. You do not say how your parseLine methods return a Matcher, nor how they would be null. I don’t like returning null, because you might try to use the null and suffer a NullPointerException. And currentPageCache is an ArrayList<String>. Armed with this information, let’s see whether we can get rid of the breaks.

    public int currentlyLoggedIn()
    {
        int returnVal = 2;
        for (Iterator<String> it = currentPageCache.iterator(); it.hasNext() && returnVal == 2;/*empty*/)
        {
             String each = it.next();
             if (parseLine(each,"id=\"login\"") != null)
             {
                 returnVal = 0;
             }
             if (parseLine(each, "Logout</a>") != null)
             {
                 returnVal = 1;
             }
        }
        return returnVal;
    }

Why are you returning a Matcher object and not using it? That seems very strange.

But we have got rid of the breaks.

A lot of people would disagree and say there is nothing wrong withbreak.

[Jeff Verdegan]

Campbell Ritchie wrote:It is never OK to go against the style guide

I'm afraid I'm gonna have to go ahead and disagree with you there. I would say it's okay to go against the style guide when doing so increases readability.

[Nick Singh]

Why are you returning a Matcher object and not using it? That seems very strange.

The parseLine(String a, String b) method takes an html line (param1) and attempts to match param2 against it. It's used throughout the script and not just here. The reason it returns a Matcher and not a boolean is because many of the other methods will need to use the Matcher objects methods, it just happens that in this case, whether a match was made or not determines whether the user is logged in or logged out.

And for the null returns, I'm a bit of a greenhorn, totally missed how that would be a problem till you mentioned it. That is against the style guide too! :P

Also, the only reason I never used enums is because I have no experience with them.

for (Iterator<String> it = currentPageCache.iterator(); it.hasNext() && returnVal == 2;/*empty*/)

Ha, never thought of that