The naming convention for getters are normally,

getAutoLogin() if getting some string or object.

isAutoLogin() for boolean.

Traditionally, getters are prefixed with get or is for the value. This is often mentioned in java style guides. For example Java Programming Style Guide (this is just one example).

The convention for such method names is occasionally enforced in tools that use reflection or expect certain styles of code. For example, again in Java (though JSP’s Expression Language), ${foo.bar} will be translated into the call foo.getBar() when the jsp is compiled. The getValue() is enforced in this way so that it becomes more than just a convention.

As mentioned, the above examples are from Java. This is a convention for Java. Other languages have other conventions that should be looked at and likely followed too. Some languages use properties (and can do other neat things with them like copy on request or read only).

Look into the style guides for your particular language choice. It is probably a good idea to follow them when possible so that other coders, when reading your code, will more quickly be able to get into the code without trying to figure out your personal style.

Naming a method in a cleverly readable way has advantages. Naming methods so that their intent and nature is easy to derive from the name (“getters have prefix get, boolean predicates, is“) has advantages, too.

It’s up to you to strike a balance, but in a large project benefits of consistency usually outweigh those of accidental cleverness.

Renaming a method to make the name both readable and convention-conformant is a nice daily exercise. In your particular case I’d consider something like isAutoLoginEnabled or getAutoLoginFlag.

OTOH you you have a bunch of conceptually similar methods that all can follow the pattern of shouldDoSomething, your original name can be fine, too.

I always find that code should be as human readable as possible. It helps to clearly define the intentions of the code.
In your case think about what both the positive and negative uses of your boolean and how it would impact readability and the intentions of your logic would be.

if(!shouldAutoLogin)
{
     ....
}

versus

if(!getShouldAutoLogin)
{
    ....
}

Which gives a clearer meaning to the intention of what the code is trying to do?

As others have suggested, I would even rename the variable to

isShouldAutoLogin

or similar

I tend to write getAutoLogin when I want the method to return a data type, like an int or a String. However, if I want to check if it’s true or false (boolean), I simply swap the get to an is like this: getAutoLogin > isAutoLogin. I believe there is a naming convention for every language.