Bools and code maintainability

There's a lot of silly arguing happening on twitter about booleans as a code smell. As far as I can make out it originates from Alex Curran's post Clean code: The curse of a boolean parameter.

I used the example getAddress(true) - from the calling code it's unclear what on earth the boolean does. The response to this was:

'If all you have is the calling code (no docs, no access to the source) there's your problem. Once again, the issue is not the boolean itself'

This is a strange position, let's say the boolean is a flag, an argument named singleLine, this implies some logic in the getAddress(boolean singleLine) method that will return two differently formatted addresses, one multiline, and another, an overview on a single line (that means the method is doing two things, but that's another argument). All that's needed to improve code readability (and therefore maintenance) is two methods instead of one:

getAddress();  
getAddressPreview();

I have occasionally resorted to including a final boolean in a class to improve readabiltiy where I can't refactor some api, eg:

private static final boolean SINGLE_LINE = true;
//...
getAddress(SINGLE_LINE);

is preferable to getAddress(true), and tidier to my eye than:

//argument is a flag denoting singleLine
getAddress(true);

Another slightly specious response was:

getAddress(1)
ints are a code smell

In this instance I would say unless the int is representing an array index a similar argument applies, eg:

private static final int MODE_CONSISE = 0;
private static final int MODE_FULL = 1;

public Address getAddress(int mode){
    //...
}

//Calling code:
Address address = someClass.getAddress(SomeClass.MODE_FULL);

While much more readable you're still increasing the cyclomatic complexity of your code. The possible entropy in your codebase increases, more openings for bugs to creep in. It almost always makes more sense to have multiple accessors, rather than one with a config flag: fewer possible states == fewer bugs.