My variables are a little more verbose than the anemic style preferred by Rob Pike and used throughout K&R but, in that tradition, I also tend towards shorter, simpler variable names than something like minValueForTemperature, so maybe it would be useful to illuminate my own thinking.

Complex variable names ought to be avoided because, simply, they hammer the programmer with a bunch of information every time they are used. Usually, when reading code, you're trying to wrap your head around how a procedure operates rather than the specifics of what it's operating on. Often, if you need to know more about what a variable represents, it's sufficient to refer to its declaration.

Thusly, I prefer to name my variables so that one can pick up the general idea of what they're for from the name and then I document any additional information at the variable's declaration, either using a comment or via the type system.

So, this is how I'd handle your examples:

    int maxval; /* until overflow */
    Temperature minval;

If you're dealing with temperatures, a better name than minval or minValueForTemperature might be mintemp, min_temp, or minTemp depending on your style. One reason to use moderately short variable names is so that reading the name is faster. Include the most important information in the name, infer the rest from context. If you find you still need a lot of context, drop something less important from the name (e.g. minval->mintemp).

I'd also avoid putting prepositions into variable names, but that's just a personal preference for keeping things to one adjective plus one noun where possible (less parsing overhead for my brain).

Keeping variable names short is a natural brake on routine length. Like wrapping at 80 columns and using tabs is a natural brake on deeply nested conditionals.

If I need a longer variable name to clarify the intent of the code, it's a signal from the code that maybe I should break the routine into smaller pieces.

I also find that smaller variable names makes it way faster to scan and thus understand.

YMMV ...