É uma má prática nomear uma variável não utilizada com um único sublinhado?


44

Freqüentemente, quando a sintaxe do idioma exigir que eu cite uma variável que nunca é usada, eu o nomeei _.

Na minha opinião, isso reduz a desordem e me permite focar nas variáveis ​​significativas no código. Acho que é discreto e produz um efeito "fora da vista, fora da mente".

Um exemplo comum de onde eu faço isso é nomear subconsultas no 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

Uso essa técnica com moderação, apenas quando sinto que um nome descritivo não adiciona nada ao código e, em certo sentido, o tira adicionando mais nomes para lembrar. De certa forma, eu a vejo como semelhante à varpalavra - chave em C #, que também uso com moderação.

Meus colegas de trabalho discordam. Eles dizem que mesmo ter um nome de caractere único (alfabético) é melhor que _.

Estou errado? É uma prática ruim fazer isso?


4
Eu acho que nomes de variáveis ​​devem seguir a teoria da informação, ou seja, o comprimento é a probabilidade recíproca de log de seu uso (variáveis ​​comuns têm nomes abreviados). Uma única letra alfabética parece ser o caminho errado.
Dan_waterworth

2
@dan_waterworth O uso de caracteres únicos ou duplos como aliases de tabela é uma prática bastante comum em scripts SQL. Como você normalmente precisa escrever muitos [table].[column]identificadores, ajuda muito a legibilidade para usar [T].[column]. Depende do roteiro, é claro. Um pouco de seleção assim é perfeitamente correto, mas se um script for muito grande, eu poderia usar nomes mais descritivos.
CodexArcanum

5
Eu prefiro que você use "manequim". Isso me grita que eles estão lá porque a linguagem requer uma variável que não tem contexto semântico fora dessas poucas linhas. _ não lê bem para um humano. (uma das razões que eu odeio PERL - Eu não posso escrevê-lo ou lê-lo)
Chris Cudmore

1
Nota lateral: O que você está nomeando é uma tabela derivada , não uma subconsulta.
Nick Chammas

2
A palavra-chave var em c # não tem esse significado, é apenas uma declaração de variável normal em que o tipo é inferido.
Francesco De Vittori

Respostas:


60

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 for, 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.


13
+1. dummyseria bom, joined_abseria melhor.
Blrfl

5
+1, existe uma convenção em que trabalho para usar '_' para variáveis ​​não utilizadas. Eu acho que é uma boa convenção, mas concordo com esta resposta para o caso do OP. O ideal é que as bases de código pareçam ter sido escritas por uma única pessoa.
Dan_waterworth

20
"_" é um padrão conhecido no Python.
Neil G

2
Se sua empresa usa algum Perl, por outro lado, usar $ _ pode causar um comportamento às vezes surpreendente.
Plutor

2
No prólogo, um sublinhado indica que a variável será anônima e, portanto, não utilizada.
470 Ivan

44

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 muitos idiomas, principalmente nos idiomas funcionais baseados em ML, como Haskell e OCaml, é extremamente comum o uso _como uma variável "não utilizada". Mesmo Lua, que não oferece suporte explícito à linguagem, incentiva o uso _como espaço reservado por convenção.

Vários idiomas (Haskell, Lua e DI pensam em detalhes) também oferecem uma convenção em que variáveis ​​que começam com um sublinhado não geram avisos do compilador sobre "variável local não utilizada", que torna _o nome mais curto da variável não utilizada. Você poderia usar algo parecido, _unusedmas eu concordo com você que isso causa confusão.


No caso específico do SQL, considerei isso e os colegas de trabalho podem estar corretos aqui. Geralmente, uso uma única letra maiúscula para alias de tabela (e geralmente R (esults) para sub-seleções). Eu acho que usar *selects é uma coisa muito ruim, porque se a tabela mudar, o conjunto de resultados também mudará inesperadamente. Então, eu normalmente precisaria do alias de caractere único para identificar as colunas que estou selecionando. Se você parar de usar *, para de precisar de um nome "não utilizado".
CodexArcanum

11
A rigor, pelo menos em Haskell, _é um padrão, não uma variável. É uma diferença sutil, mas significa que você pode usá-lo várias vezes em algo como (x, _, _) = ..., enquanto tentar vincular a mesma variável várias vezes seria um erro.
Hammar 5/05

12

Em Python _é definitivamente aceitável. No entanto, pode entrar em conflito com o gettextalias _().

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 emitem avisos de variáveis ​​não utilizados:

  • PyLint para _oudummy
  • PyDev para qualquer variável iniciada por _, unusedoudummy

2
Além disso, o uso _de variáveis ​​dummy em python colidirá com o _último valor retornado. Por exemplo, no intérprete, se você faz 5*5na linha 1; então na linha 2 _terá o valor 25. No entanto, se você definir x,_ = (3,'not used'), você descobrirá que _agora é not usedo último valor retornado até você del _. Você provavelmente não deveria estar usando o _último valor retornado em código real; mas muitas vezes é útil no intérprete ao experimentar coisas novas.
dr jimbob

4
Bem, _como o último valor retornado, funciona apenas no shell interativo.
vartec 4/04/12

O mesmo vale para Lua. Usando _ é padrão prática
Sylvanaar

11

Depende do ecossistema em que esse código irá residir. Se _for um padrão aceito para indicar "variável dummy" / "saída não utilizada", então, por todos os meios, continue com ele. Caso contrário, descubra o que é e use isso.

Algumas linguagens de programação (por exemplo, Haskell) têm esse identificador 'especial' incorporado em sua sintaxe exatamente para os fins mencionados.


5

Cuidado, _ já tem um significado intrínseco em algumas línguas

Em Python:

9.6 Variáveis ​​privadas e referências de classe local

insira a descrição do link aqui Variáveis ​​de instância "privadas" que não podem ser acessadas, exceto de dentro de um objeto, não existem no Python. No entanto, existe uma convenção seguida pela maioria dos códigos Python: um nome prefixado com um sublinhado (por exemplo, _spam) deve ser tratado como uma parte não pública da API (seja uma função, um método ou um membro de dados) . Deve ser considerado um detalhe da implementação e sujeito a alterações sem aviso prévio.

Há também outra menção no PEP 8 (Guia de estilo para código Python):

Descritivo: Estilos de Nomenclatura

_single_leading_underscore: fraco indicador de "uso interno". Por exemplo, de M import * não importa objetos cujo nome comece com um sublinhado.

Em c #:

Geralmente é usado para marcar variáveis ​​privadas que possuem propriedades públicas / internas. Mas a prática geralmente é menosprezada atualmente .

Em JavaScript:

Existe 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áveis ​​de espaço reservado clássico.

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 mal quando já existem muitas convenções comuns disponíveis?


No Scala: é o símbolo curinga / espaço reservado, mas como espaço reservado você pode se referir a ele apenas uma vez .
Rex Kerr

@RexKerr Interessante. Sinta-se livre para editar isso na resposta, se quiser. Eu faria, mas não estou familiarizado com scala.
Evan Plaice

Um comentário deve servir. Qualquer pessoa que use o Scala saberia, e qualquer pessoa que não use o Scala provavelmente não teria compatibilidade com o Scala no topo de sua lista de razões para / não fazer algo.
Rex Kerr

Eu acho que usar um desses espaços reservados de "convenção" para variáveis ​​não utilizadas seria uma prática ruim, pois me faria pensar, primeiro, "por que diabos esse cara não nomeou essa coisa melhor?" e depois de um tempo eu descobriria que era porque a variável não é usada.
Igorantos07

@ igorsantos07 Eu concordo completamente. Minha preferência seria dar um nome descritivo, mesmo para variáveis ​​temporárias. O objetivo desta resposta é demonstrar por que o sublinhado não é uma boa opção para uma convenção de nomenclatura; devido ao seu significado preexistente em vários idiomas.
Evan solha

2

Eu uso "manequim" para esse tipo de coisa. Ou "porcaria", se eu estiver testando algo :) Nomeie suas variáveis ​​para descrever quais são elas. Se forem variáveis ​​fictícias e não utilizadas, nomeie-as como tal.


0

Acho que é uma prática ruim porque

  • você não deve ter variável invisível no seu código. Se você acha que deveria, o motivo provavelmente pode ser discutido.

  • o idioma 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 retornos múltiplos, não será necessário. Sua convenção de nomenclatura o prejudicará no dia em que você usará um idioma usando _ como uma notação de idioma padrão.

(Não conheço Python: essa construção é realmente necessária?)


2
Se você usá-lo para filtrar vários retornos, é apenas conseqüente usá-lo também para argumentos de função fictícia. De fato, não há muita diferença entre os dois: nas linguagens funcionais de correspondência de padrões, você pode escrever let (a,b,_) = f(x,y,z)tão bem quanto o que let f(x,y,_) = (g(x),h(x),g(y))quer. - E, sim, muitas vezes é útil ter parâmetros fictícios: não como a única definição de uma função, mas para uma função polimórfica ou com definições alternativas de correspondência de padrão é frequentemente a coisa natural a se fazer.
leftaroundabout

1
O seu segundo ponto contradiz o seu ponto principal: no Go, isso significa essencialmente o mesmo que "Não tenho utilidade para esse valor".
Casey Kuball

0

Pode ser sintaticamente válido e pode ser bom 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. É apenas mais difícil de ler, e não super significativo.


0

Eu acho que está errado porque:

1) É mais difícil de ver, pois não há muitos pixels.

2) Se houver mais de um _, como você sabe qual? - ou que um novo desenvolvedor 'seguiu as regras' e manteve o uso extremamente local no escopo?

3) É uma prática que não ajuda. Usar nomes de variáveis ​​com uma letra é tão antigo (ou seja, minha educação original!). Vou vê-los ... e depois adicionar comentários para dizer o que o código faz e isso é uma prática ruim no mundo de hoje. Eu uso nomes de variáveis ​​longos, tanto quanto possível, para que todos, independentemente do nível de programação ou familiaridade com o código, possam "lê-lo" quase como em inglês. Usar nomes de uma letra é uma prática extremamente comum com códigos mais antigos e com programadores mais antigos (mais uma vez, inclui-me), mas isso não o faz bem.


9
"como você sabe qual" você não : esse é exatamente o ponto, você não usa a variável. Portanto, também não importa se _já está sendo usado em um escopo externo; esse será obscurecido (ou seja o que for que seu idioma fizer nesses casos), mas nenhum deles será realmente usado.
leftaroundabout

0

Para evitar colisões de namespace e permitir a depuração, caso esse nome de variável seja sua única pista, talvez seja melhor chamá-lo de "join_ab_unused".

Inspirado por Birfl.


0

Sim, é uma prática ruim por dois motivos:

  1. Prefixar uma variável não utilizada com um sublinhado não é um padrão amplamente aceito. Provavelmente será ignorado o "não iniciado".
  2. Eu já vi algumas pessoas prefixarem variáveis ​​de membros particulares com um sublinhado, e seu padrão confundiria muito essas pessoas.

0

O que você está tentando fazer é codificar uma versão mais agradável do SQL, que não tem 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 o espaço em branco pudesse ser usado como identificador, seria perfeito, certo?

Mas você não está em um idioma diferente, e o que está fazendo não é uma maneira limpa de fazer uma extensão de idioma.


0

Depende do idioma. Em java , sim, isso é ruim e pode ser uma tendência perigosa a ser adicionada 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áveis ​​java. Em python , isso também é ruim, mas não tão ruim. No clojure , é 100% aceitável e, de fato, é idiomático para usar _ como espaço reservado em uma declaração let.

Lembre-se de que cada idioma tem sua própria sintaxe e um conjunto de expressões idiomáticas; portanto, você deve avaliar o que é bom / ruim em termos desses idiomas, e não em termos absolutos.


5
Não concordo que isso seja uma má prática em python. É uma convenção amplamente compreendida
Daenyth

0

Isso seria ruim no perl, que usa $ _ (e às vezes _) como uma variável especial.

Em geral, eu ficaria longe disso apenas porque o _ parece ser uma variável específica do idioma. Se eu visse seu código, eu estaria na documentação procurando o que era _, até que percebi que era apenas um manequim. Nada de errado com DUMMY, $ DUMMY, qualquer que seja.


0

Eu evitaria sublinhados no início dos vars, a menos que você tivesse certeza de que eles não tendem a indicar outra coisa em um determinado idioma ou estrutura em uso pesado. Por exemplo, em Python, um sublinhado duplo tende a indicar uma var mágica. No JQuery e em outras bibliotecas JS, um único sublinhado tende a indicar uma var de fallback para substituições de namespace. Também é uma convenção de nomenclatura popular para arquivos de inclusão que, por sua vez, tendem a ser transferidos para o código que manipula inclusões na forma de var.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.