Muitas vezes, quando a sintaxe da linguagem exige que eu nomeie uma variável que nunca é usada, eu a nomeio _ .
Na minha opinião, isso reduz a desordem e permite que eu me concentre nas variáveis significativas do código. Eu acho que é discreto, de modo que produz um efeito "fora da vista, fora da mente".
Um exemplo comum de onde eu faço isso é nomear subconsultas em SQL.
SELECT *
FROM
(
SELECT *
FROM TableA
JOIN TableB
ON TableA.ColumnB = TableB.ColumnB
WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC
Outro exemplo é uma variável de loop que não é usada.
array = [[] for _ in range(n)] # Defines a list of n empty lists in Python
Eu uso essa técnica com muita parcimônia, apenas quando sinto que um nome descritivo não adiciona nada ao código e, em certo sentido, retira-o, adicionando mais nomes a serem lembrados. De certa forma, vejo isso como semelhante à palavra-chave var em C #, que também uso com moderação.
Meus colegas de trabalho não concordam. Eles dizem que mesmo ter um único caractere (alfabético) é melhor que _ .
Estou errado? É uma prática ruim fazer isso?
Todos os nomes devem ser significativos. Se _ fosse um padrão bem conhecido na sua empresa ou na comunidade em geral, seria significativo como um "nome que não importa". Se não é, eu diria que é uma má prática. Use um nome descritivo para o que você se refere, especialmente porque o nome pode ser importante no futuro.
Eu diria que é uma prática aceitável. Este é um caso raro em que considero que a maioria está errada e precisa atualizar seus conhecimentos sobre idéias de programação recentes. Em muitas linguagens, particularmente em linguagens funcionais baseadas em ML, como Haskell e OCaml, é extremamente comum usar _ como uma variável "não usada". Até mesmo a Lua, que não oferece suporte explícito ao idioma, incentiva o uso de _ como um espaço reservado por convenção.
Várias linguagens (Haskell, Lua e DI pensam em cima da minha cabeça) também oferecem uma convenção em que as variáveis que levam a um sublinhado não geram avisos do compilador sobre "variável local não utilizada" que torna _ o menor nome da variável não utilizada. Você poderia usar algo como _unused , mas eu concordo com você que isso só faz bagunça.
Em Python _ é definitivamente aceitável. No entanto, pode entrar em conflito com gettext alias _() .
Outras convenções comuns são dummy , unused ; sozinho ou como prefixo.
Algumas ferramentas de análise de código estão cientes dessas convenções e não emitirão avisos de variáveis não usados:
Depende do ecossistema em que este código vai viver. Se _ for um padrão aceito para indicar "variável dummy" / "saída não usada", então, por favor, continue com isto. Se não for, descubra o que é e use isso.
Algumas linguagens de programação (por exemplo, Haskell) até têm esse identificador "especial" embutido em sua sintaxe exatamente para os propósitos que você menciona.
Cuidado, _ já tem um significado intrínseco em alguns idiomas
Em Python:
9.6. Private Variables and Class-local References
enter link description here“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.
Há também outra menção no PEP 8 (Guia de Estilo para o Código Python):
_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.
Em C #:
Geralmente é usado para marcar variáveis privadas que possuem propriedades públicas / internas. Mas a prática é geralmente menosprezada nos dias de hoje .
Em JavaScript:
Há uma biblioteca chamada underscore.js que usa o sublinhado como um prefixo para extensões de protótipo não padrão.
Exemplo:
var object = { some:'stuff' };
var newObject = _.clone(object);
O que me leva ao meu ponto. O que há de errado com as convenções de variável de espaço reservado clássicas.
var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders
Por que usar uma convenção personalizada que alguns podem interpretar erroneamente quando já existem muitas convenções comuns disponíveis?
Eu uso "dummy" para esse tipo de coisa. Ou "porcaria", se eu estou apenas testando algo :) Nomeie suas variáveis para descrever o que elas são. Se forem variáveis falsas e não usadas, nomeie-as como tal.
Acho que é uma prática ruim porque
você não deve ter uma variável invisível no seu código. Se você acha que deveria o motivo provavelmente poderia ser discutido.
a linguagem Go usa essa palavra-chave para indicar que nenhuma variável é o destino de um dos vários retornos de uma função. Se o seu idioma não tiver vários retornos, não será necessário. Sua convenção de nomenclatura afetará você no dia em que usar uma linguagem usando _ como uma notação de idioma padrão.
(Eu não sei Python: esta construção é realmente necessária?)
Ele pode ser sintaticamente válido e pode estar certo como parte de um padrão.
Com isso dito, é algo que eu pediria a alguém para alterar em uma revisão de código. Eu também nunca o colocaria em um padrão de codificação e tentaria removê-lo de um já existente. É mais difícil de ler e não é super significativo.
Eu acho errado porque:
1) É mais difícil de ver porque não há muitos pixels.
2) Se houver mais de um _ , como você sabe qual deles? - ou que um novo desenvolvedor "seguiu as regras" e manteve seu uso extremamente local no escopo?
3) É uma prática que não é útil. Usar nomes de variáveis de letras simples é tão antigo (ou seja, minha educação original!). Eu os vejo ... e vejo comentários adicionados para dizer o que o código faz e isso é uma má prática no mundo de hoje. Eu uso nomes longos de variáveis tanto quanto possível para que todos, independentemente do nível de programação ou familiaridade com o código, possam apenas "ler" quase como inglês. Usar nomes de 1 letra é uma prática extremamente comum com código antigo e com programadores mais antigos (mais uma vez, inclui-me), mas isso não faz com que seja ok.
Para evitar colisões de namespace e permitir a depuração, caso o nome da variável seja sua única pista, talvez seja melhor chamá-la de "joined_ab_unused".
Inspirado por Birfl.
Sim, é uma prática ruim por dois motivos:
O que você está tentando fazer é codificar uma versão melhor do SQL que não tenha o problema de forçar você a inventar um nome para algo inútil.
O sublinhado é quase invisível, então parece que você está nesse idioma. Se apenas espaço em branco pudesse ser usado como um identificador, seria perfeito, certo?
Mas você não está em um idioma diferente e o que você está fazendo não é uma maneira clara de fazer uma extensão de idioma.
Depende da linguagem. Em java , sim, isso é ruim e pode ser uma tendência perigosa para adicionar ao seu código, principalmente porque as ferramentas que usam reflexão não lidam com sublinhados muito bem, pois estão fora das convenções de nomenclatura de variável java. Em python , isso também é ruim, mas não tão ruim. Em clojure , seus 100% estão bem, e de fato, é idiomático usar _s como marcadores em uma declaração let.
Lembre-se de que cada idioma tem sua própria sintaxe inteira e um conjunto de expressões idiomáticas, portanto, você precisa avaliar bem / mal em termos dessas expressões, e não em termos absolutos.
Isso seria ruim em perl, que usa $ _ (e às vezes _) como uma variável especial.
Em geral, eu ficaria longe disso apenas porque o _ parece ser uma linguagem específica e variável. Se eu visse seu código, estaria na documentação procurando o que era, até que percebi que era apenas um idiota. Nada de errado com DUMMY, $ DUMMY, o que quer que seja.
Eu evitaria sublinhados no início de vars, a menos que você tivesse certeza de que eles não tendem a indicar algo em um determinado idioma ou estrutura em uso pesado. Por exemplo, no Python, um sublinhado duplo tende a indicar uma var. Mágica. Na JQuery e em outras bibliotecas JS, um único sublinhado tende a indicar uma variável de fallback para sobrescritos de namespace. Também é uma convenção de nomenclatura popular para incluir arquivos que, por sua vez, tendem a ser transferidos para códigos que manipulam inclusões em formato var.