Mas, se for para manter padrão com a convenção de alguma coisa, ótimo. É uma boa idéia preferir um código mais uniforme.

Pelo menos, esse é um prefixo simples e fácil de lembrar.

E, definitivamente, uma das grandes vantagens do Java é que eles optaram por criar e divulgar uma convenção de código única. No C++, você corre o risco de usar a Ogre com essa convenção, associada com uma Engine de física com outra convenção e uma biblioteca de IA com uma terceira…

Existe um problema em usar TAB: Se você trocar para um editor com a tabulação de tamanho diferente, ferra todo o código. A maior parte dos editores suporta usar TAB ou espaços, geralmente configurável através de opção. E, diferente do que você falou, eu tenho visto hoje em dia eles configurados para espaços (code::blocks, eclipse, netbeans e o do Delphi já aderiram à esse padrão). Não duvido que o Visual suporte isso também.

propriedades da classe prefixadas com m, por exemplo

class Enemy{

public:
   int mLife;
   void setLife(int life){
      mLife=life;
   }
};

é um padrão também usado na Ogre e que venho me acostumando com ele

ourta questão, é a da identação, acredito que na maioria dos compiladores é o TAB, eu uso o Visual C++ Express (está longe de ser um Eclipse da vida ), e para identar o código automaticamente seleciona-se o código e faz-se a combinação CTRL+K CTRL+F

vlw, e parabéns pelo blog!

Os leitores como eu^^
E como muitas pessoas que chegam até aqui vem do GUJ acho que se acostumarão mais facil.

Primeiramente, não há diferença significativa em termos de performance. A maior parte dos compiladores disponíveis hoje em dia (e testei isso no MinGW e no Visual C++) é esperta o suficiente para gerar exatamente o mesmo código para os dois casos.

Ainda que não gerasse, duvido muito que esse tipo de otimização em microcódigo gerasse algum tipo de ganho significativo. Primeiro, porque a comparações envolvendo ponteiros dessa forma são bastante esporádicas. Segundo, porque a maior parte dos gargalos está em algoritmos mal implementados, IO e na parte gráfica.

Por fim, também achei conveniente adotar essa convenção porque tenho certeza de que terei leitores Java e leitores pouco experientes com C++, que certamente se sentirão mais à vontade com ela.