Sure, we can always find difficult issues - the idea is to find ways to make our code more readable and understandable for whoever has to maintain it. My style has changed a lot over the passed 44 years of coding and it is still changing as I discover better ways of making my code more reliable and more maintainable. It's really frustrating, for example, when I am reading someone elses code that makes it impossible to tell a local variable from a class level variable - maybe that does not bother you but it does me. I certainly welcome any ideas for making my code better; however, not doing the best that I can to let the reader know about the type, scope, and usage of a variable is a non-starter for me.

I use the class name only with a leading lower case letter for local and add m_ for class level s_ for static and p_ for parameter - it's easy. It may look ugly but it's clear.

Custom types are easy - I just use the class name only starting with a lower case letter

Well, I am a firm believer in Hungarian and here is why - I believe that the name of a variable should instantly convey three vital pieces of information to the dev: - it's type and I do mean type as in compiler typeof not semantics (regardless of what Charles did or did not intend) - it's scope - is it local, a parameter, is it a passed in reference, a class level variable - a clear indication of it's function or purpose Different devs have their own view on how to write code; however, I believe that it's better to have a good logical reason for a belief rather than just a prejudice. I believe that one of the reasons that Hungarian is considered bad is due to the way that many devs implement it - that is, each group uses very short abbreviations that are not clear to someone who is not part of the team so when you look at another teams code, you have to learn their abbreviations. Different teams have different rules and different ways of implementing Hungarian which make it a hassle to read another teams code. I believe that it is not Hungarian that is the problem but rather the way that it is implemented that is the problem. First we do very little abbreviation and only if it is an abbreviation that is so common that a noob would clearly understand it. We use longer names - yes we believe in self documenting code which means my manager should be able to read my code and understand what is being implemented in general terms (we don't however go to extremes). If a passed in parameter is a reference that will live after a function is finished, then it is important to know that altering it can have long term consequences. If a variable is a class level variable, it is extremely important to know. It should also be obvious that the more accurate the variable name clearly indicates it's purpose and function, the less potential there is for another dev to misunderstand or the original dev when returning to old code. Saying that Intellisense will solve the problem or that we can mouse over a variable is not a solution because when we read code and think we understand, we rarely mouse over or use Intellisense on what we think we already understand. Saying that Hungarian is bad because the type might change is a really weak argument - in the first place, types don't usually change that much; second, if a type does change, I certainly want to know; and lastly, with today's IDE refactoring capability, is really that hard to change a variable name (it's certainly easy for me). We c

You could use Susie Linux - it comes with Mono built in.