As variáveis / membros iniciais com um sublinhado podem confundir o compilador?

Eu aprendi desde o ensino médio que definir variáveis como esta:

int _a;

int __a;

deve ser considerada uma prática ruim, porque isso acabaria confundindo os compiladores que usam variáveis que começam com um sublinhado para nomear variáveis temporárias.

Até onde eu sei, essa é a razão pela qual algumas pessoas gostam de mover o sublinhado no final do nome, como:

int a_;

No entanto, vejo um monte de código ao redor que faz uso de variáveis de início de sublinhado. E esse código cria bastante bem com o Visual Studio 2010 e o g ++ 4.x.

Então eu me pergunto: isso não é problema hoje em dia? Os compiladores modernos são mais inteligentes quanto às convenções de nomenclatura?

c++ programming-practices naming-standards

— Emiliano
fonte

Não é uma resposta real, mas é provável que os compiladores C ++ da Microsoft sejam especificamente mais tolerantes com isso, porque é estilo interno da Microsoft usar sublinhados antes de variáveis de membros particulares (pelo menos em C #). Eu sei que o g ++ ainda pode ter problemas com os principais sublinhados.

— KChaloux

Você pode encontrar as respostas para esta pergunta útil.

— Blrfl

@KChaloux Se você acha que a equipe de compiladores C ++ da Microsoft, existente há mais de 20 anos, estabeleceu as regras sobre nomes de identificadores aceitáveis com base nos hábitos de algumas pessoas na equipe de C #, você não sabe como a Microsoft funciona :-). Sério, já se passaram 21 anos desde que eles lançaram seu primeiro compilador C ++ e essas regras remontam tão longe, ou ainda mais na base de código do compilador C original.

— Kate Gregory

@ Kate, eu estava apenas apontando que sabia que eles o usavam em c #. Eu não uso o compilador C ++ da Microsoft, nem sei muito sobre o ambiente lá, então deduzi o uso desse estilo de nomeação em C ++ a partir da minha experiência com C #. Nunca fez quaisquer alegações de que o C # regra veio primeiro.

— KChaloux

Respostas:

Aparentemente, você está entendendo mal o motivo pelo qual os sublinhados de prefixo são uma má prática. Para encurtar, é porque o padrão C e C ++ reserva esse prefixo para detalhes de implementação, por exemplo, para implementação de biblioteca padrão. (observe que _ e __ não estão reservados para as mesmas coisas, consulte os comentários)

Mesmo que os nomes estejam no escopo (namespace, classe etc.), pode haver alguns nomes globais, em particular macros, que usam esse prefixo e podem silenciosamente interromper seu código, se você também os usar.

Portanto, basicamente, na maioria das vezes, é seguro usar esses prefixos, mas se você não os usar, terá 100% de garantia de que sua nomeação nunca entrará em conflito com os nomes de implementação.

É por isso que, na dúvida, não use esse prefixo.

— Klaim
fonte

seus comentários aplicam-se ao prefixo de dois sublinhados, mas não para um único sublinhado

— Kate Gregory

@KateGregory: os nomes com um sublinhado à esquerda são reservados para uso pela implementação de nomes no espaço para nome global. Um sublinhado inicial seguido de um segundo sublinhado ou maiúsculo é reservado para qualquer uso (eles podem ser usados para macros pela implementação). Portanto, um sublinhado à esquerda seguido de uma letra minúscula pode ser bom nos escopos locais, mas é melhor evitar evitar tropeçar e usar um nome reservado.

— Bart van Ingen Schenau,

@ KateGregory: Como membro, _limitnão é um erro, mas como uma função global. Eu acho que é melhor ter uma política simples que diga "não use sublinhados líderes, sem exceção" do que uma política que permita isso em alguns contextos e não em outros. Mas podemos concordar em diferir nisso. E só para esclarecer, não tenho problemas com sublinhados em outros lugares além do início.

— Bart van Ingen Schenau

@BartvanIngenSchenau: apenas por interesse: uma política simples como "usar sublinhados líderes apenas e somente para alunos particulares" não deve levar a problemas técnicos, o que você acha que é verdade?

— Doc Brown

@KateGregory Apenas para esclarecer, concordo que as regras são mais precisas do que estou dizendo na minha resposta; mas reflete a falta de precisão da minha memória quando tento lembrar quais são exatamente as regras. Como evito ter que conhecer exceções (não o recurso), prefiro regras gerais fáceis de seguir, principalmente para regras não tão importantes. O mais engraçado é que estou mais à vontade com o movimento semântico do que me lembrar disso. Talvez isso não é divertido, agora que penso nisso ...

— Klaim

O uso de dois sublinhados é definitivamente ruim - reservado para detalhes de implementação específicos do compilador. Isso não se aplica ao uso de um sublinhado.

Algumas pessoas odeiam sublinhados. Se você chama alguma coisa m_indexou highest_priceou _a- eles a detestam. Trabalhei com alguém de 25 anos atrás que me falou sobre uma impressora IBM específica (muito popular) que se encaixava em mais linhas na página, omitindo o pixel inferior em todas as outras linhas. Isso era bom para memorandos ou para a saída de grandes quantidades de números e afins, mas teve o efeito de tornar invisível a metade de seus sublinhados. (Sim, de verdade!) As pessoas dessa geração geralmente têm o ódio sublinhado irracional, seja pela interação com a impressora ou por trabalhar com alguém que se depara com essas sublinhados que não devem ser usadas.

A maioria das pessoas encontrar usando letras maiúsculas e minúsculas (uma opção que não tinha em, digamos, Fortran) uma abordagem mais legível: mIndex, HighestPrice, alevantar-se muito bem aos exemplos anteriormente sublinhadas. Vou lhe dar duas regras:

nunca inicie nada (função, variável, macro, typedef) com dois sublinhados
escolha uma convenção consistente (por exemplo, _limitpara parâmetros de função, m_limitpara variáveis-membro, nunca use sublinhados, maiúsculas e minúsculas, coloque todas as palavras em maiúscula, húngaro, algo assim ) e atenha-se a elas. Não se intrometa às vezes com sublinhados no começo, às vezes no final, às vezes sem usá-los e com cinco convenções diferentes. Ser consistente.

A impressora em questão já se foi. Se você gosta de usar um sublinhado de cada vez, sinta-se à vontade para. Mas entenda, os ódios sublinhados ainda existem.

— Kate Gregory
fonte

"Quer você chame algo de m_index ou preço mais alto ou _a - eles detestam isso" Não sem razão! Você não mencionou que existem regras nos padrões referentes especificamente ao uso dos sublinhados principais nos identificadores. Por que pedir problemas quando é tão facilmente evitado? stackoverflow.com/a/228797

— Max Barraclough

não fez menção? Leia a primeira frase novamente.

— Kate Gregory

"Isso não se aplica ao uso de um sublinhado" não é a história toda, veja meu link, que diz que liderar com sublinhado duplo é um não-não muito definido, mas que "Reservado no espaço de nome global: identificadores começando com um sublinhado ". Por que brincar com fogo?

— precisa

ok, você está perdendo o objetivo. O segundo parágrafo discute a existência de pessoas que são, em geral, anti-sublinhado. Não está sublinhado à esquerda. Todos os sublinhados. Sim, é verdade que, além da regra sobre dois sublinhados, também existe uma regra sobre sublinhados iniciais, seguida por uma letra maiúscula, sublinhados principais no escopo global etc., mas, além disso, algumas pessoas odeiam os sublinhados. E essas pessoas são o que eu gosto de chamar de errado. Não há motivo baseado em padrões para objetar sublinhados não-líderes. Mas as pessoas fazem assim mesmo.

— Kate Gregory

É aí que discordamos. Sim, às vezes é legal iniciar um identificador com um único sublinhado. Como disse acima, por que brincar com fogo? Eu nunca inicio um identificador com um sublinhado; Eu vejo isso como um cheiro de código (se é possível dizer que 'visualiza' um cheiro :-P). Dessa forma, nunca me preocupo com as especificidades das regras que me dizem exatamente quando é legal fazê-lo.

— precisa

As variáveis ​​/ membros iniciais com um sublinhado podem confundir o compilador?

As variáveis / membros iniciais com um sublinhado podem confundir o compilador?