Functions can be as short as you want, even as small as one line. Decent compilers will inline the code if it makes sense to do so, so don't worry that it will add overhead.

As for a single line null check-- that might make sense if the null check is on a private variable, or if the caller wouldn't normally think to do the null check, e.g.

bool IsDataValid {
    return _privateValue != null;
}

But if the null check would also make sense to the caller, it might make better sense to expect the caller itself to perform the null check against one of the class' fields.

myClass = Factory.GetMyClass();
if (myClass.PublicField != null) {
    //Do Something
}

It really depends on what results in the most readable code.

Can a function be too short?

Not really.... functions can be as short as you want, even as small as one line. Decent compilers will inline the code if it makes sense to do so, so don't worry that it will add overhead.

Should a simple logical operation be encapsulated in a method?

As for a single line null check-- that might make sense if the null check is on a private variable, or if you consider the knowledge of nullability to be internal, e.g. the caller wouldn't normally think to do the null check himself because it is an implementation detail and not an intuitive aspect of the class's interface.

bool IsDataValid {
    return _privateValue != null;
}

But if the null check would also make sense to the caller, it might make better sense to expect the caller itself to perform the null check against one of the class' fields.

myClass = Factory.GetMyClass();
if (myClass.PublicField != null) {
    //Do Something
}

It really depends on what results in the most readable code.

What are some guidelines on size?

1. A function should be as short as possible.

2. A function may grow if it needs to enforce sequential coupling rules, e.g. if there are several steps that need to happen in a particular order. On the other hand, the individual steps could be farmed out to separate functions if the function gets too big.

3. A function may grow if all of its steps require access to a common but temporary set of local variables, and it would be cumbersome to propagate those variables by including them as input parameters to separate, smaller functions. On the other hand, if there are a ton of variables and the function gets very large and complicated, you could move the function to its own class and promote the local variables to member variables, using the Command design pattern.

4. A function may grow if consolidation into a single operation makes for a cleaner interface for the caller, e.g. a business level function that wraps an atomic transaction, or a function that represents a unit of work. Again, that doesn't mean the function can't farm out logical steps to various other functions (which might be scoped private so they can't be called directly from outside the class).

5. In general, a function or method should be readable without scrolling your code pane, if possible.

6. Developers should strive to minimize cyclomatic complexity in their functions, e.g. minimize the number of possible logic paths. Minimizing complexity has been shown empirically to reduce coder error and defect rate.