IMO short names are perfectly acceptable and even preferable as a local variable names withing short functions, when context is obvious and everything fits onto one screen. I would prefer

    for (int i = 0, len = string.length(); i <= len; i++) {
        char c = string.charAt(i);
        if (c == '\t') {
            return true;
        }
    }
    return false;

rather than something like

    boolean tabFound = false;
    int stringLength = string.length();
    for (int characterIndex = 0; characterIndex <= stringLength; characterIndex++) {
        char character = string.charAt(characterIndex);
        if (character == '\t') {
            tabFound = true;
        }
    }
    return tabFound;

Naming a variable solely after its type is never particularly useful. A name like `currentChar` would probably enhance readability. Of course if your code is just 2 lines long, `c` works just fine (that's not usually the case though).

You should probably abstract away some of that logic though (and `string` isn't a great variable name either):

    boolean tabFound = includes(line, '\t');

How would you name an abstract string without any implied meaning?

If the functionality you're writing is truly that abstract, an abstract variable name is fine. Your example didn't include the method signature though, so I assumed it was a part of some larger (concrete) code block.

> list comprehensions

Yes. Very much yes. My personal rule is to _always_ use single-letter names for Python comprehension indices, because line length is the biggest enemy of readability there.

In my experience, one-character variables are serviceable, even preferable, when you're piping data, like Streams in java, or all the equivalent functions in rust. So long as the starting input's type is clear, the "capturing" variable can be just the first letter of the type.