Em caso de dúvida, soletre.
O objetivo de um nome de variável é para que o significado do código seja mais claro. A menos que a abreviação seja muito óbvia, você também pode usar a menor possível. Nomes de variáveis e nomes de funções são normalmente os únicos bits da linguagem humana no código e, portanto, agem como 'marcos' para o olho humano encontrar partes relevantes do código (ou, em uma grande base de código, ferramentas como grepou ack) e também como pistas. para compreensão.
Quando a próxima pessoa ler seu código, ela agradecerá. Essa pessoa pode muito bem ser você daqui a um ano. Eu tenho muito código que lamento abreviar, então hoje em dia eu tento evitá-lo.
Não há problema em abreviar quando ...
... Quando o formulário abreviado é usado no inglês falado ou escrito por mais do que apenas as pessoas que trabalham no seu projeto (muitos dicionários fornecem esse tipo de informação ao lado do termo que definem).
var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation
... Quando a abreviação se refere inequivocamente a um único conceito e seria instantaneamente reconhecida por alguém que não está familiarizado com a base de código. Mesmo assim, um comentário ou uma documentação ajuda.
var auth = user.auth;
if (auth) // If the user is authenticated?
// If the user is authorised to do something?
// If the authentication function exists for that user group?
// If some setting called auth is turned on for that user?
// If the user is the author of the document in question?
// If the user has some authority?
var attrNames = retrieveAttrs();
if (attrNames) // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!
const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name
... Quando o nome da variável existir apenas em um único escopo ou função pequena e você não esperar que o usuário obtenha significado do nome, use um único caractere. Em tais casos, ie jsão comuns.
foreach $i (1..10) { say $announcement->[$i] }
... Ao escrever uma interface (ou seja, não um nome de variável, portanto fora do escopo da pergunta, mencionado apenas porque nomes de variáveis e interfaces que os definem costumam usar o mesmo vocabulário), nesse caso outras regras podem ser aplicadas, por exemplo:
some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done" # if you can spare -m
... Quando sua base de código precisar se referir ao mesmo conceito várias vezes no mesmo projeto e quando a abreviação puder ser definida em um guia de estilo para esse projeto e quando for inequívoco. Se o seu projeto não é grande o suficiente para um guia de estilo, não é grande o suficiente para valer a pena.
Não vou fornecer um exemplo de código para este porque, por definição, ele funciona apenas em um projeto grande, mas veja também o próximo item:
... Ao trabalhar em um projeto estabelecido que teve vários colaboradores e um guia de estilo que exige abreviações. Nesse caso, abrevie apenas de acordo com o guia de estilo, mas procure problemas e esteja preparado para fazer anotações com comentários (como "esta é uma lista de nomes de atributos como seqüências de caracteres").
Os tipos devem terminar em "_t"; Definições de estrutura bruta em "_struct"
- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt
Um pensamento final: se você ainda possui nomes de variáveis inaceitavelmente longos (por exemplo, compostos por quatro ou mais unidades semânticas como totalAfterTaxInLocalCurrency), pode ser um sintoma de que seu código está tentando fazer muito em um único escopo e que suas funções precisam ser refatoradas out ou suas variáveis podem ser mais logicamente gerenciadas em um único objeto.