>1. What is the expected practice for naming controls? frmLogon, btnName, txtInput etc?

I name most controls that way; not Forms for some reason, but txt and cbo, definitely, btn or cmd (VFP holdover, obviously <g>), etc.

>2. Is camelCase still best policy for variable naming?

Depends on who you talk to. I typically use PascalCase rather than camelCase for variables and properties. Mike mentioned using an underscore for class-level member variables. Personally, the underscore-only prefix makes me cringe ... I don't know why, I just don't like it. The only time I use underscores is for member variables that I'm going to expose as Properties, and then I use m_ (yes, another holdover from VFP ... but I've seen people without a VFP background do this too, so it must be come from somewhere else also).

>3. Should variable names begin with and identifier of their type? intCounter, strBuffer etc?

Absolutely NOT! Not necessary, harder to read.

>I know in reality it will not make my code run faster/better but I would like to follow standard practice. Are there any other "recommended practices" that would be different to what I am used to in VFP?

It's been so long since I've done VFP that I can't think of anything off the top of my head. One practice that you definitely *should* continue is to sub-class all of your controls (TextBox, ComboBox, Form, etc), first thing, and only use your sub-classes in your apps. Even if you have nothing at all in your sub-classes at first ... trust me, you'll add to them eventually. <g> Some of these can't be sub-classed visually (Forms can, but most others can't), but that's not a problem really. I have a short blog post about it if you're interested:
http://geek-goddess-bonnie.blogspot.com/2009/10/why-and-how-to-sub-class-base-classes.html

~~Bonnie