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.

What's your preference for interface naming? What do other languages use?

Most folks I know just name them after what they do. The "I" is usually just used for iteration

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.

I've typed enough long diatribes on this to not want to repeat any of them today, but the short version is that I tend to do whatever the standard libraries do, because the standard libraries have surely encountered every odd combination of language structures and has already figured out how to name it, the number of hours gained back by simply saying I will never (again) spend time trying to come up with a better solution myself alone is worth it. This goes for types and general interface style as well as simple naming.

My C++ code tends to look like the C++ standard library in its public interface, and like Boost in the parts that hide implementation details (because the standard essentially forbids user implementation details from looking like implementation details in the standard). My C code looks like the C standard libraries. My C# code looks like those libraries, which follows the canonical C# style guide, of course.

On sort of benefit to this, is that I'm never in the situation of adopting one third-party library and then having to contend with 3 different styles (third-party style, my own style, and the standard library style), since my own style and the standard style are the same. When using Boost or another library that also adopts the standard library style I only have to deal with one.

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");

- First think I do after opening a project: format re-factoring,

- Second thing I do after opening a project: code style re-factoring.

Yes, I like break code of other people and find&replace is my favourite sex toy D: