1. No, but I have yet to encounter a case where a "count" of something is anything other than an integer type of some sort. Redundant information is not useful

1. You haven't, that's just it. It could be a DWORD, long, even an [un]signed integer larger or smaller than 32-bits. Or it could even be a float or double. In that case, what if I just assume it's a standard 32-bit integer and try to do a bitwise operation on it?
2. The word "count" doesn't tell you much right off the bat, except what it's used for.

1. Why are you doing bitwise operations on a counter variable? A counter is something that counts. If you're going to do further operations on a counter then it has effectively ceased to be a counter and has become something else, in which case you should just create another variable or rename the old one with a name that better reflects what you're actually doing.

To be totally fair, I actually have seen this done.

On much older platforms, like the NES, some games perform bitwise operations on the global frame counter to control background animations.

So I heard you like systems hungarian

auto utMyVariable = foobar();

// ut, of course stand for "unknown type" 

The argument I've seen for hungarian on count variables is that if gives you a pretty decent snapshot of the size range of the count, and any possible bugs that it might cause.

Someone doing some subtraction on an unsigned integer? overflow warning bells pop off. Same if someone is using a short or int or whatever for something that is going to have fairly insane counts.

That said, it's still ugly to look at, and not that useful, especially these days, where most of the time I can either hover over it and get a tooltip, or right click or use some keyboard shortcut to look at the definition of the variable.

EDIT: And to rerail: Sure, the coding style on an engine matters, but it would only really be a problem if it was super ugly, or just had an incomprehensible style.

I am a solo programmer, but I do read others' source code every now and then. I also have my own style, which isn't as set in stone as it should be.

The one thing I value above all, however, regardless of the coding style used, is clarity. Unless you are indeed reading code on the web, the type info part of a variable's name should be made moot by the IDE.

That being said, I do use it occasionally in interface-level code to differentiate between ambiguous types or when the type is non-trivial:

TEXTUREHANDLE smpTextureSamplerName
HANDLE thdThreadName
SharedPtr<wchar_t> wString

But not in places where the reader can tell the type with 99% certainty or, if they want to be 100% sure, they can casually hover over the variable name and the IDE does their work for them.

In other words, I can appreciate type information to stress or draw attention to an unexpected type, much like composers add accidentals in parentheses to speed up reading the sheet music if there's enough confusion surrounding the note that its sign may not be instantly clear.

Writing out every type every time a variable name is used is as overly verbose as adding an accidental before every note.

Code clarity and simplicity is my primary reason to consider an engine. That's the main reason I use Leadwerks.

Model* model = Model::Load("Models/barbarian.mdl");