As constantes de um único caractere são melhores que as literais?

Tautologia :

It is very clear if you read the very first sentence of the question that this question is not about appropriate uses like eliminating magic numbers, it is about terrible mindless foolish consistency at best. Which is what this answer addresses

O senso comum informa que const char UPPER_CASE_A = 'A'; ou const char A = 'A' não adiciona nada além de manutenção e complexidade ao seu sistema. const char STATUS_CODE.ARRIVED = 'A' é um caso diferente.

Constantes devem representar coisas que são imutáveis em tempo de execução, mas podem precisar ser modificadas no futuro em tempo de compilação. Quando const char A = seria corretamente igual a algo diferente de A ?

Se você vir public static final char COLON = ':' no código Java, encontre quem escreveu isso e quebre seus teclados. Se a representação para COLON mudar de : , você terá um pesadelo de manutenção.

Ofuscação:

O que acontece quando alguém o altera para COLON = '-' , porque onde eles estão usando ele precisa de um - em todo lugar? Você vai escrever testes de unidade que digam basicamente assertThat(':' == COLON) para cada referência de const para garantir que eles não sejam alterados? Apenas para que alguém conserte o teste quando eles forem alterados?

Se alguém realmente argumentar que public static final String EMPTY_STRING = ""; é útil e benéfico, você apenas qualificou seu conhecimento e os ignorou com segurança sobre todo o resto.

Ter todos os caracteres imprimíveis disponíveis com uma versão nomeada apenas demonstra que quem o fez não está qualificado para escrever código não supervisionado.

Coesão:

Também reduz artificialmente a coesão, porque afasta as coisas das coisas que as usam e estão relacionadas a elas.

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highly cohesive systems functionality is strongly related.

Acoplamento:

Ele também une muitas classes não relacionadas, porque todas elas acabam referenciando arquivos que não estão realmente relacionados ao que eles fazem.

Tight coupling is when a group of classes are highly dependent on one another. This scenario arises when a class assumes too many responsibilities, or when one concern is spread over many classes rather than having its own class.

Se você usou um nome melhor como DELIMITER = ',' , você ainda teria o mesmo problema, porque o nome é genérico e não carrega nenhuma semântica. A reatribuição do valor não faz mais para ajudar a fazer uma análise de impacto do que pesquisar e substituir o literal ',' . Porque o que é algum código usa e precisa do , e algum outro código usa mas precisa de ; agora? Ainda tem que olhar para cada uso manualmente e alterá-los.

Em estado selvagem:

Recentemente, refatorei um aplicativo 1,000,000+ LOC com 18 anos de idade. Tinha coisas como public static final COMMA = SPACE + "," + SPACE; . Isso não é de forma alguma melhor do que apenas inlining " , " onde é necessário.

Se você quiser argumentar legibilidade você precisa aprender a configurar seu IDE para exibir whitespace caracteres onde você possa vê-los ou o que for, isso é apenas uma razão extremamente preguiçosa para introduzir a entropia um sistema.

Ele também tinha , definido várias vezes com vários erros de ortografia da palavra COMMA em vários pacotes e classes. Com referências a todas as variações misturadas juntas no código. Não foi nada menos que um pesadelo tentar consertar algo sem quebrar algo completamente não relacionado.

Mesmo com o alfabeto, havia vários UPPER_CASE_A , A , UPPER_A , A_UPPER que na maioria das vezes eram iguais a A mas em alguns casos não eram . Para quase todos os personagens, mas nem todos os personagens.

E a partir dos históricos de edição, não parece que um único deles tenha sido editado ou alterado ao longo de 18 anos, por causa do que agora deve ser óbvio, porque isso quebraria muitas coisas que não eram rastreáveis, assim você tem novos nomes de variáveis apontando para a mesma coisa que nunca pode ser alterada pelo mesmo motivo.

Em nenhuma realidade sensata, você pode argumentar que esta prática não está fazendo nada além de iniciar a entropia máxima.

Refatorizei toda essa bagunça e inlinei todas as tautologias e as novas contratações da faculdade foram muito mais produtivas porque elas não tinham que caçar através de vários níveis de indireção o que essas referências const apontavam, porque elas não eram confiável em que eles foram nomeados vs o que eles continham.

The main appeal of using constants is they minimize maintenance when a change is needed.

ABSOLUTAMENTE NÃO. Isto não é de todo o motivo para usar constantes porque as constantes não mudam por definição. Se uma constante alguma vez muda então não foi uma constante, foi?

O recurso de usar constantes não tem nada a ver com gerenciamento de mudanças e tudo a ver com tornar programas passíveis de serem escritos, compreendidos e mantidos por pessoas . Se eu quiser saber em todos os lugares do meu programa onde um caractere de dois-pontos é usado como um separador de URL, posso saber isso muito facilmente se tiver a disciplina para definir um URLSeparator constante e não puder saber disso facilmente se tiver que procurar : e obtém todos os lugares no código onde : é usado para indicar uma classe base, ou um operador ?: , ou o que for.

Eu discordo completamente das outras respostas que afirmam que isso é uma perda de tempo sem sentido. Constantes nomeadas adicionam significado a um programa, e essas semânticas podem ser usadas tanto por seres humanos quanto por máquinas para entender um programa mais profundamente e mantê-lo mais efetivamente.

O truque aqui não é evitar constantes, mas nomeá-las com suas propriedades semânticas ao invés de suas propriedades sintáticas . Para que serve a constante? Não chame de Comma , a menos que o domínio comercial do seu programa seja tipografia, análise de idioma inglês ou algo semelhante. Chame isso de ListSeparator ou algo assim, para deixar clara a semântica da coisa.

Não, isso é burro.

O que é não necessariamente idiota é colocar coisas assim em rótulos nomeados por motivos de localização. Por exemplo, o delimitador de milhares é uma vírgula na América (1.000.000), mas não uma vírgula em outras localidades. Puxar isso em um rótulo nomeado (com um nome apropriado, não-vírgula) permite que o programador ignore / abstraia esses detalhes.

Mas fazer uma constante porque "cordas mágicas são ruins" é apenas o cultivo de carga.

Existem alguns caracteres que podem ser ambíguos ou usados para várias finalidades diferentes. Por exemplo, usamos '-' como um hífen, um sinal de menos ou até mesmo um traço. Você poderia criar nomes separados como:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '-';
static const wchar_t EM_DASH = '-';

Mais tarde, você pode optar por modificar seu código para desambiguar redefinindo-o como:

static const wchar_t HYPHEN = '-';
static const wchar_t MINUS = '\u2122';
static const wchar_t EM_DASH = '\u2014';

Esse pode ser um motivo pelo qual você considera a definição de constantes para determinados caracteres únicos. No entanto , o número de caracteres que são ambíguos dessa maneira é pequeno. No máximo, parece que você faria isso apenas por aqueles. Eu também diria que você poderia esperar até que você realmente tivesse a necessidade de distinguir os caracteres ambíguos antes de fatorar o código dessa maneira.

Como as convenções tipográficas podem variar de acordo com o idioma e a região, provavelmente é melhor você carregar essa pontuação ambígua em uma tabela de tradução.

Uma constante deve adicionar significado.

Definir COMMA como vírgula não adiciona significado, porque sabemos que uma vírgula é uma vírgula. Em vez disso, destruímos o significado, porque agora o COMMA pode não ser mais uma vírgula.

Se você usar uma vírgula para um propósito e quiser usar uma constante nomeada, nomeie-a após sua finalidade. Exemplo:

• city + CharacterClass.COMMA + state = ruim
• city + CITY_STATE_DELIMITER + state = bom

Use funções para formatar

Eu pessoalmente prefiro FormatCityState(city, state) e não me importo com a aparência do corpo dessa função, contanto que seja curto e passe nos casos de teste.

A ideia de que um COMMA constante é melhor que ',' ou "," é bastante fácil de desmistificar. Claro que há casos em que faz sentido, por exemplo, fazer com que final String QUOTE = "\""; economize bastante na legibilidade sem todas as barras, mas com exceção de caracteres de controle de idioma como \ ' e " eu não achei muito útil.

Usar final String COMMA = "," não é apenas uma forma ruim, é perigoso! Quando alguém deseja alterar o separador de "," para ";" , ele pode alterar o arquivo de constantes para COMMA = ";" , porque é mais rápido fazê-lo e simplesmente funciona. Exceto, você sabe, todas as outras coisas que usaram COMMA agora também são ponto e vírgula, incluindo coisas enviadas para consumidores externos. Portanto, ele passa todos os seus testes (porque todo o código de empacotamento e desmarque também estava usando COMMA), mas os testes externos falharão.

O que é útil é dar-lhes nomes úteis. E sim, às vezes várias constantes terão o mesmo conteúdo, mas nomes diferentes. Por exemplo, final String LIST_SEPARATOR = "," .

Portanto, sua pergunta é "são constantes de caracteres únicos melhores que literais" e a resposta é inequivocamente não, eles não são. Mas ainda melhor do que ambos é um nome de variável com escopo limitado que explicitamente diz qual é o seu propósito. Claro, você gastará alguns bytes extras nessas referências extras (assumindo que elas não serão compiladas em você, o que elas provavelmente farão), mas na manutenção de longo prazo, que é onde a maior parte do custo de um aplicativo é, elas valem a pena fazer.

Eu fiz algum trabalho escrevendo lexers e parsers e usei constantes inteiras para representar terminais. Terminais de caractere único passaram a ter o código ASCII como valor numérico para simplificar, mas o código poderia ter sido algo totalmente diferente. Então, eu teria um T_COMMA que foi atribuído o código ASCII para ',' como seu valor constante. No entanto, também havia constantes para não-terminais que foram designados inteiros acima do conjunto ASCII. Olhando para geradores de parser como yacc ou bison, ou analisadores escritos usando essas ferramentas, fiquei com a impressão de que é basicamente assim que todos faziam isso.

Assim, enquanto, como todo mundo, acho inútil definir constantes com o propósito expresso de usar as constantes em vez dos literais em todo o código, acho que há casos extremos (parsers, digamos) onde você pode encontrar código cheio de constantes como você descreve. Observe que, no caso do analisador, as constantes não estão lá apenas para representar literais de caracteres; eles representam entidades que podem apenas acontecer serem literais de caracteres.

Eu posso pensar em mais alguns casos isolados, onde pode fazer sentido usar constantes em vez dos literais correspondentes. Por exemplo, você pode definir NEWLINE como o literal '\ n' em uma caixa unix, mas '\ r \ n' ou '\ n \ r' se você estiver no windows ou mac box. O mesmo vale para analisar arquivos que representam dados tabulares; você pode definir as constantes FIELDSEPARATOR e RECORDSEPARATOR. Nestes casos, você está realmente definindo uma constante para representar um personagem que serve uma certa função. Ainda assim, se você fosse um programador iniciante, talvez nomeasse seu separador de campo constante COMMA, sem perceber que deveria tê-lo chamado FIELDSEPARATOR e, quando percebesse, o código estaria em produção e você estaria na próxima projeto, então a constante nomeada incorretamente ficaria no código para alguém para depois encontrar e balançar a cabeça em.

Por fim, a prática descrita pode fazer sentido em alguns casos em que você escreve código para manipular dados codificados em uma codificação de caracteres específica, digamos iso-8859-1, mas espera que a codificação mude mais tarde. É claro que, em tal caso, faria muito mais sentido usar bibliotecas de localização, codificação e decodificação para lidar com isso, mas se por algum motivo você não pudesse usar uma biblioteca como essa para lidar com problemas de codificação, usando constantes você só tem que redefinir em um único arquivo, em vez de literais codificados espalhados por todo o seu código-fonte pode ser um caminho a percorrer.

Quanto ao artigo ao qual você se vinculou: não acho que tente argumentar sobre a substituição de literais de caracteres por constantes. Eu acho que está tentando ilustrar um método para usar interfaces para extrair constantes em outras partes de sua base de código. As constantes de exemplo usadas para ilustrar isso são muito mal escolhidas, mas acho que elas não importam de forma alguma.

Além de todas as respostas bem aqui, eu gostaria de acrescentar como alimento para o pensamento, que uma boa programação é fornecer abstrações apropriadas que podem ser construídas sozinho e talvez outros, sem ter que repetir o mesmo código repetidamente.

Boas abstrações tornam o código fácil de usar, por um lado, e fácil de manter, por outro lado.

Eu concordo totalmente que DELIMITER=':' em si é uma má abstração, e apenas melhor que COLON=':' (já que esta última é totalmente empobrecida).

Uma boa abstração envolvendo strings e separadores incluiria uma maneira de empacotar um ou mais itens de conteúdo individuais na string e descompactá-los da string empacotada também, antes de mais nada, antes de dizer a você qual é o delimitador. Tal abstração seria agrupada como um conceito, na maioria das linguagens como uma classe; por exemplo, para que seu uso seja praticamente auto-documentável, em que você pode procurar todos os lugares onde essa classe é usada e ter certeza da intenção do programador em relação ao formato das cadeias compactadas em cada caso em que alguma abstração é usada.

Uma vez que essa abstração seja fornecida, seria fácil usá-la sem precisar consultar o valor do DELIMITER ou COLON e, alterar os detalhes da implementação geralmente seria limitado à implementação. Então, em resumo, essas constantes devem ser realmente detalhes de implementação escondidos dentro de uma abstração apropriada.

The main appeal of using constants is they minimize maintenance when a change is needed.

Boas abstrações, que são tipicamente composições de vários recursos relacionados, são melhores para minimizar a manutenção. Primeiro, eles separam claramente o provedor dos consumidores. Segundo, eles ocultam os detalhes da implementação e, em vez disso, fornecem funcionalidade diretamente útil. Terceiro, eles documentam em alto nível quando e onde estão sendo usados.

A única vez em que vi essas constantes usadas efetivamente é corresponder a uma API ou documento existente. Eu vi símbolos como COMMA usados porque um determinado software estava diretamente conectado a um analisador que usava COMMA como tag em uma árvore de sintaxe abstrata. Eu também vi isso usado para corresponder a uma especificação formal. em especificações formais, às vezes você verá símbolos como COMMA em vez de ',' , porque eles querem ser o mais claro possível.

Em ambos os casos, o uso de um símbolo nomeado como COMMA ajuda a fornecer coesão a um produto que, de outra forma, seria separado. Esse valor muitas vezes supera o custo de notações excessivamente verbosas.

Observe que você está tentando fazer uma lista.

Portanto, refatore-o como: String makeList(String[] items)

Em outras palavras, fatore a lógica em vez dos dados .
Os idiomas podem ser diferentes em como eles representam listas, mas as vírgulas são sempre vírgulas (isso é uma tautologia). Então, se a linguagem mudar, mudar o caractere de vírgula não ajudará você - mas isso vai acontecer.

Se esta foi uma aula escrita como parte de uma aplicação pelo seu colaborador, esta é quase certamente uma má ideia. Como outros já apontaram, faz sentido definir constantes como SEPARATOR = ',' , onde você pode alterar o valor e a constante ainda faz sentido, mas muito menos constantes, cujo nome descreve apenas seu valor.

No entanto, existem pelo menos dois casos em que faz sentido declarar constantes cujo nome descreve exatamente seu conteúdo e onde você não pode alterar o valor sem alterar apropriadamente o nome da constante:

• Constantes matemáticas ou físicas, por ex. %código%. Aqui, o papel da constante é agir como um mnemônico, pois o nome simbólico PI = 3.14159 é muito mais curto e mais legível do que o valor que representa.
• Listas exaustivas de símbolos em um analisador ou teclas em um teclado. Pode até mesmo fazer sentido ter uma lista de constantes com a maioria ou todos os caracteres Unicode e é aí que o seu caso pode cair. Alguns caracteres, como PI , são óbvios e claramente reconhecíveis. Mas você pode facilmente dizer A e А aparte? O primeiro é letra cirílica enquanto o último é letra latina A . São letras diferentes, representadas por diferentes pontos de código Unicode, embora graficamente sejam quase idênticas. Eu prefiro ter constantes A e CYRILLIC_CAPITAL_A no meu código do que dois caracteres quase idênticos. Claro, isso é inútil se você sabe que estará trabalhando somente com caracteres ASCII que não contêm cirílico. Da mesma forma: eu uso o alfabeto latino no dia-a-dia, então se eu estivesse escrevendo um programa que precisava de um caractere chinês, eu provavelmente preferiria usar uma constante em vez de inserir um caractere que eu não entendo. Para alguém que usa caracteres chineses no dia-a-dia, um caractere chinês pode ser óbvio, mas um caractere em latim pode ser mais fácil de representar como uma constante nomeada. Então, como você vê, depende do contexto. Ainda assim, uma biblioteca pode conter constantes simbólicas para todos os caracteres, pois os autores não podem saber antecipadamente como a biblioteca será usada e quais caracteres podem precisar de constantes para melhorar a legibilidade em um aplicativo específico.

No entanto, esses casos geralmente são tratados por classes de sistema ou bibliotecas de propósito especial e sua ocorrência no código escrito por desenvolvedores de aplicativos deve ser muito rara, a menos que você esteja trabalhando em algum projeto muito especial.

Talvez.

As constantes de caractere único são relativamente difíceis de distinguir. Por isso, pode ser bastante fácil perder o fato de que você está adicionando um período em vez de uma vírgula

city + '.' + state

Considerando que é um erro relativamente difícil de fazer com

city + Const.PERIOD + state

Dependendo do ambiente de internacionalização e globalização, a diferença entre um apóstrofo ASCII e o apóstrofo de abertura e fechamento do Windows-1252 (ou aspas duplas ASCII e aspas duplas abertas e fechadas do Windows-1252) pode ser significativa e é notoriamente difícil para visualizar o código.

Agora, presumivelmente, se erroneamente colocar um período em vez de uma vírgula fosse um problema funcional significativo, você teria um teste automatizado que encontraria o erro de digitação. Se o seu software está gerando arquivos CSV, eu esperaria que sua suíte de testes descobriria rapidamente que você tinha um período entre a cidade e o estado. Se o seu software deve ser executado para clientes com uma variedade de configurações de internacionalização, presumivelmente, seu conjunto de testes será executado em cada ambiente e será ativado se você tiver uma cotação aberta da Microsoft se quiser ter um apóstrofo.

Eu poderia imaginar um projeto em que fazia mais sentido optar por um código mais detalhado que pudesse evitar esses problemas, especialmente quando você tem um código mais antigo que não tem um conjunto de testes abrangente, embora eu provavelmente não codificasse Desta forma, em um projeto de desenvolvimento de campo verde. E adicionar uma constante para cada caractere de pontuação, em vez de apenas aqueles que são potencialmente problemáticos em sua aplicação específica, é provavelmente um exagero excessivo.

Are single-character constants better than literals?

Existem muitas conflações por aqui. Deixe-me ver se consigo separá-los.

As constantes fornecem:

• semântica
• mudar, durante o desenvolvimento
• indireto

Indo para o nome de um único caractere afeta apenas a semântica. Um nome deve ser útil como comentário e claro no contexto. Deve expressar significado, não o valor. Se ele pode fazer tudo isso com um único caractere bem. Se não puder, por favor, não faça isso.

Um literal e uma constante podem mudar durante o desenvolvimento. Isso é o que traz a questão do número mágico. As cordas também podem ser números mágicos.

Se o significado semântico existe, e desde que ambos são constantes, então, se a constante tem mais valor do que um literal, ele se torna indireto.

A indicação pode resolver qualquer problema, além de muita indireção.

A indicação pode resolver o problema do número mágico porque permite que você decida sobre um valor para uma ideia em um só lugar. Semanticamente, para que valha a pena, o nome deve fazer o que essa ideia é clara. O nome deve ser sobre a ideia, não o valor.

A indicação pode ser exagerada. Alguns preferem pesquisar e substituir literais para fazer suas alterações. Tudo bem, contanto que 42 seja claramente o sentido da vida e não misturado com 42, o número atômico de molibdênio.

Aonde você pode fazer distinções úteis como essa com uma única letra depende muito do contexto. Mas eu não faria disso um hábito.

Como contraponto filosófico à opinião da maioria, devo afirmar que alguns de nós, que apreciamos o programador camponês francês do século XIX e que não é sofisticado,

remembered his monotonous, everlasting lucidity, his stupefyingly sensible views of everything, his colossal contentment with truisms merely because they were true. "Confound it all!" cried Turnbull to himself, "if he is in the asylum, there can't be anyone outside."

G.K. Chesterton, The Ball and The Cross

Não há nada de errado em apreciar a verdade e não há nada de errado em afirmar a verdade, especialmente quando se fala de um computador.

If you lie to the computer, it will get you

Perry Farrar - Germantown, Maryland (from More Programming Pearls )

Mas, na maioria das vezes, eu concordo com as pessoas que dizem que é burro. Eu sou jovem demais para ter aprendido a programar FORTRAN, mas ouvi dizer que você poderia redefinir 'A' = 'Q' e criar todos os tipos de criptogramas maravilhosos. Você não está fazendo isso.

Além dos problemas do i18n criados antes (que não estão redefinindo o glifo "COMMA", mas redefinindo verdadeiramente o glifo de um DECIMAL_POINT). Construir citações britânicas de cadáveres ou citações britânicas para transmitir significado aos seres humanos é coisa e aquelas que realmente deveriam ser variáveis, não constantes. A constante seria AMERICAN_COMMA := ',' e comma := AMERICAN_COMMA

E, se eu estivesse usando um padrão de construtor para construir uma consulta SQL, preferiria ver

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(" ( ")
 .append(val_1)
 .append(",")
 .append(val_2)
 .append(" ); ")

do que qualquer outra coisa, mas se você fosse adicionar constantes, seria

INSERT_VALUES_START = " ( "
INSERT_VALUES_END = " ) "
INSERT_VALUES_SEPARATOR = " , "
QUERY_TERMINATOR = ";"

sb.append("insert into ")
 .append(table_name)
 .append(" values ")
 .append(INSERT_VALUES_START)
 .append(val_1)
 .append(INSERT_VALUES_SEPARATOR)
 .append(val_2)
 .append(INSERT_VALUES_END)
 .append(QUERY_TERMINATOR)

No entanto, se você já assistiu a mais alguém programar (ou digitar), poderá notar algumas peculiaridades interessantes. Nem todos nós somos digitadores estelares. Muitos de nós começaram a programar tarde ou foram criados com teclados soviéticos (onde as teclas digitam em você) e gostamos de cortar e colar letras individuais em vez de tentar encontrá-las no teclado e / ou confiar no preenchimento automático.

Nada vai preencher automaticamente uma string para você, então se eu puder obter uma vírgula pressionando 'con', alt-space, down, down, down, digite e obtenha uma citação pressionando 'con', alt-space , para baixo, para baixo, entre. Talvez eu faça exatamente isso.

Outra coisa a lembrar sobre literais de string é a maneira como eles são compilados. Pelo menos em Delphi (que é a única linguagem que eu obcecado com a pilha de) você vai acabar com seus literais colocados na pilha de cada função. Então, muitos literais = muita sobrecarga de função; "," em function_A não é o mesmo bit de memória que um "," em function_B ". Para combater isso, existe uma" string de recursos "que pode ser construída e ligada de lado - e é assim que eles fazem i18n stuff (matando dois pássaros com um arbusto) Em Python todos os seus literais de string são objetos, e pode parecer legal usar utils.constants.COMMA.join(["some","happy","array","strings"]) , mas não é uma idéia estelar para os pontos repetidos várias vezes nesta página.

But when are we going to start using a different symbol than ',' to represent a comma?

Para localização.

Nos países de língua inglesa, o símbolo que separa as partes inteira e fracionária de um decimal é ".", que chamamos de "ponto decimal". Em muitos outros países, o símbolo é "," e é normalmente chamado o equivalente de "vírgula" no idioma local. Da mesma forma, onde os países de língua inglesa usam "," para separar grupos de três dígitos em grandes números (como 1.000.000 por um milhão), os países que usam uma vírgula como ponto decimal usam um ponto (1.000.000).

Portanto, há um caso para criar constantes DECIMAL_POINT e COMMA se você estiver fazendo globalização.