como descobrir se os erros de ortografia no código-fonte são um problema sério ou não? [fechadas]

14

Encontro uma quantidade muito problemática de erros ortográficos que vejo todos os dias em nossa base de código, da qual vou reproduzir um exemplo muito curto, mas representativo:

ArgumnetCount
Timeount
Gor message from queue 

Infelizmente, isso não é de forma alguma limitado a uma pessoa. Há muitos falantes de inglês não nativos em nossa equipe que contribuem para isso, no entanto, eu também posso identificar alguns dos piores erros de ortografia para o nosso arquiteto de software que é americano, nascido e criado.

Eles também podem ser encontrados até mesmo em e-mails, apresentações, documentos, qualquer informação escrita que tenhamos em uma empresa de desenvolvimento de software.

Gostaria de saber como descobrir se é um problema sério ou não?

Eu sempre encontrei esses erros ortográficos com preocupação, mas minha própria política pessoal oficial é que não somos pagos para soletrar as coisas corretamente, somos pagos para fazer as coisas Então, dentro da empresa, eu nunca critiquei ninguém sobre isso. Mas eu levantei essa questão com alguns de meus amigos mais próximos e nunca resolvi isso de uma vez.

    
por Andrei G 02.03.2012 / 10:45
fonte

14 respostas

19

Erros de ortografia podem significar uma de duas coisas:

  • A pessoa que os faz não tem proficiência em inglês e não tem tempo para compensar usando ferramentas apropriadas (dicionários, corretores ortográficos, etc.)
  • A pessoa que os faz tem proficiência em inglês, mas não se preocupa com a ortografia.

Ou é um sinal bastante ruim, porque significa que a pessoa em questão não tem legibilidade, manutenção e elegância no topo de sua lista de prioridades; se a causa for falta de proficiência na língua inglesa, isso também significa que a pessoa não tem duas habilidades essenciais - comunicação escrita em inglês e um sentimento geral de idiomas (se você não consegue expressar seus pensamentos claramente em inglês, é possível t expressá-los bem em uma linguagem de programação também).

Mas por que exatamente os erros de ortografia são ruins, sendo todos os outros iguais? Afinal de contas, o código funciona, e o compilador não se importa como você nomeia seus identificadores, desde que eles não violem as regras de sintaxe. A razão é que escrevemos código não apenas para computadores, mas também e principalmente para humanos. Se não fosse esse o caso, ainda estaríamos usando montagem. O código fonte é escrito uma vez, mas lido centenas de vezes durante seu ciclo de vida. Os erros ortográficos tornam a leitura e a compreensão do código-fonte mais difícil - erros leves fazem o leitor tropeçar por uma fração de segundo, muitos deles podem causar atrasos consideráveis; erros realmente ruins podem tornar o código-fonte completamente ilegível. Há outro problema, que é que a maior parte do código que você escreve será referenciada por outro código, e esse código, na maioria das vezes, é escrito por outra pessoa. Se você digitar errado seus identificadores, alguém terá que lembrar (ou procurar) não apenas o nome, mas também como exatamente está escrito incorretamente. Isso leva tempo e interrompe o fluxo de programação; e como a maioria dos códigos é tocada mais de uma vez em manutenção, cada erro de ortografia causa muitas interrupções.

Considere como o tempo de desenvolvedor é igual a salário é igual a despesas, eu acho que deve ser fácil o suficiente para fazer um caso disso; afinal, quebrar o fluxo e voltar a ele pode levar até 15 minutos. Dessa forma, um grave erro ortográfico pode facilmente custar algumas centenas de dólares em desenvolvimento e manutenção adicionais (mas são custos indiretos, não diretamente visíveis em estimativas e avaliações, de modo que muitas vezes são ignorados pela gerência).

    
por 02.03.2012 / 10:59
fonte
9

Na primeira vez que você perder tempo pesquisando a variável Timeout apenas para descobrir que ela foi escrita como Timeount , você saberá outra razão pela qual a ortografia é importante.

    
por 05.03.2012 / 23:02
fonte
8

Na verdade, duvido que "Timeount" seja uma questão de não ser um falante nativo. As pessoas fazem toneladas de erros em sua primeira língua. Eu não qualificaria esses exemplos particulares como "Engrish".

Dito isto, entendo que não é sobre esses exemplos particulares. Eu concordo com você em princípio. Eu me deparei com problemas reais causados por esse tipo de coisa ("se não houver uma coluna chamada attachements, crie anexos").

Ser um programador é ser preciso e cuidadoso com erros de digitação, vírgulas, ponto-e-vírgulas, pontos, que são agnósticos na linguagem humana na maior parte do tempo.

    
por 02.03.2012 / 11:00
fonte
7

Se esse problema incomodar você, a maioria dos IDE agora permite a verificação ortográfica nos comentários, para que os disléxicos possam pelo menos parecer que sabem soletrar. Com certeza me ajuda! Portanto, é uma "correção" trivial ter uma boa ortografia.

    
por 02.03.2012 / 11:05
fonte
6

Erros de ortografia em nomes e métodos de classe pública são simplesmente não profissionais. Eles custam tempo e dinheiro. Eles são dolorosos em linguagens estaticamente tipadas como Java, onde o IDE pode produzir um menu de nomes de classes e métodos. Eles são intoleráveis em linguagens dinamicamente tipadas.

Pior ainda são erros de ortografia em nomes de tabelas de bancos de dados e nomes de colunas.

Na minha experiência, a ortografia correta é apenas ligeiramente relacionada à proficiência em inglês do codificador. Já vi falantes nativos de inglês produzirem código com uma grafia essencialmente aleatória e quebras de palavras, e vi pessoas que não são nativas em inglês e que têm o cuidado de produzir grafias corretas. Mas a ortografia correta está altamente relacionada à qualidade geral do código. Programadores capacitados, não importa sua proficiência em inglês, se preocupam com a qualidade de seu trabalho e são cuidadosos com a nomeação.

    
por 05.03.2012 / 19:35
fonte
5

No código-fonte, apresentações e documentos internos, etc. pequenos erros de digitação que não alteram o significado ou dificultam o entendimento não são um emblema. Apenas corrija-os na fonte se achar que eles são irritantes.

Além disso, particularmente nos comentários, a substância é mais importante que o formulário. No Engrish aqui:

String s = "Wikipedia"; /* Assigns the value "Wikipedia" to the variable s. */

O fato é que algumas pessoas são naturalmente escritores mais cuidadosos do que outros (seja por educação, por atitude ou por inteligência ou qualquer outra coisa, não é relevante). Quanto gastar esforço para consertar isso é uma questão de valor de negócios: você obtém mais valor de corrigir os erros de digitação do que gasta esforço para corrigi-los? No caso de coisas internas, a resposta geralmente é não. Seus clientes não vão reclamar sobre erros de digitação nos comentários do código-fonte (a menos que você esteja fazendo código aberto).

A digitação intencional incorreta e os comentários inadequados não são profissionais e devem ser evitados, mas o foco deve estar nas coisas que importam (ou seja, gerar valor comercial, se você trabalha para negócios).

Coisas publicamente visíveis devem, é claro, ser cuidadosamente revisadas.

    
por 02.03.2012 / 11:06
fonte
4

O problema aqui não é o engrish em si, mas a falta de clareza de comentários. Inglês perfeito não é necessário, claro inglês é. É trivial para executar algo através do google para pegar os erros óbvios.

Por exemplo, não fica claro desde o primeiro olhar se Gor message from queue significa "recebeu uma mensagem da fila" ou "mensagem GOR da fila". Você precisaria ler o código para entender o significado do comentário (derrotando assim o objeto do comentário).

Você deve solicitar a implementação de análises de código em sua empresa. Você pode então "criticar" as pessoas de maneira construtiva enquanto elas fazem o mesmo com você.

    
por 02.03.2012 / 10:59
fonte
2

Deve ficar óbvio que o compilador não se preocupa com erros de ortografia, contanto que você esteja usando a mesma ortografia, por exemplo, ao referenciar uma variável. A questão, então, é se os erros ortográficos têm um impacto negativo na capacidade dos membros da equipe de manter o código.

A única maneira que vejo para fazer isso é falar com as pessoas que fazem a manutenção, e você pode começar perguntando se alguém teve mais dificuldade em seguir o código que continha erros ortográficos.

Eu não acho que haja alguma maneira de remover completamente a subjetividade deste problema, mas para reduzi-lo, você pode (manualmente ou através de um script) verificar a fonte para obter um número estimado de erros ortográficos para um módulo de código específico, e Veja se a manutenção nos módulos com um maior número de erros ortográficos levou mais tempo, em média, do que os módulos com menos erros ortográficos.

Nem todos os módulos são feitos naturalmente, então você pode pensar em ponderar seus resultados com várias métricas, como a complexidade ciclomática do módulo.

    
por 05.03.2012 / 19:36
fonte
2

Na minha experiência, esses erros básicos de ortografia são preocupantes e podem ser sintomáticos de problemas mais profundos. Todo projeto com o qual trabalhei com erros "triviais" como esse tinha problemas reais no design que de alguma forma passavam pelo processo de revisão apenas para aparecer durante o desenvolvimento, o que não é quando você quer descobrir que a funcionalidade crítica que você realmente precisa não está lá.

Eu verificaria as especificações do sistema (se elas existirem) e examinaria o design geral; Eu não ficaria surpreso se você encontrasse alguns buracos.

    
por 05.03.2012 / 22:03
fonte
1

Isso é na verdade dois problemas separados, mas relacionados. Depende de onde estão os erros ortográficos:

1) No código fonte. Se você tem um identificador como ArgumnetCount , isso pode criar problemas reais quando alguém aparece e usa a ortografia correta . Então você deve corrigir esses erros sempre que possível. Se você precisar preservar a compatibilidade de API para trás, poderá fazer algo como:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) Em texto legível por humanos (e-mails, documentação, comentários de código). Escrevê-los corretamente é importante, mas eu diria que é uma prioridade menor, já que o software de análise dentro da sua cabeça é muito mais indulgente. Se você vir um texto com alguns erros, isso ainda é legível, então não se preocupe - não é problema seu. Mas se alguém lhe enviar algum absurdo de associação livre e esperar que você use esse absurdo como plano para um aplicativo da Web multiusuário, envie uma nota educada ao autor solicitando esclarecimentos (algo como: "Você é um idiota analfabeto, como você espera que eu entenda essa merda? ")

    
por 05.03.2012 / 23:09
fonte
-1

Corrigir inglês escrito é uma obrigação no código. Eu também tenho uma grande base de código cheia de rabiscos e é um pesadelo para manter.

Não deixe que isso fique fora de controle. Tente educar a todos que os mantenedores de código não são leitores de mentes.

    
por 02.03.2012 / 11:09
fonte
-1

Bem, esse é um problema cultural multifacetado.

Falando de uma perspectiva alemã: notamos como a nossa própria língua é cada vez mais influenciada pelos termos ingleses. Isso vai tão longe quanto as empresas nacionais que têm slogans ingleses ou propaganda. Algumas pessoas, especialmente em cargos de gerência, são aparentemente incapazes de proferir apenas uma frase em alemão simples. Seu discurso é cheio de palavras de efeito e gíria de gestão incompreensível. Dizemos que essas pessoas estão falando "denglish".

Dado que este estado de coisas e o inglês são a "lingua franca" especialmente nos negócios de software, é inevitável que o próprio Inglês seja influenciado pelo vasto número de falantes não nativos. Mas para os falantes nativos de inglês isso ainda é melhor do que ter que dizer chinês para participar da indústria SW.

    
por 02.03.2012 / 11:39
fonte
-1

É cor ou cor? De qual versão do inglês você você acha que é a correta? A ortografia correta de um homem é a desculpa de outro homem para iniciar uma guerra vencível.

Se você quer começar uma guerra, escolha suas batalhas com cuidado e ganhe-as. No seu caso, não se preocupe com comentários, preocupe-se menos com internos e concentre-se (quase) exclusivamente na API

    
por 06.03.2012 / 00:15
fonte
-3

Eu tenho uma máxima: código arrumado não significa necessariamente uma mente arrumada, mas o anverso certamente é verdadeiro: código desordenado, mente desleixada.

Um programador que não usa o tempo para nomear variáveis corretamente e soletrar comentários corretamente quase certamente não está tomando tempo para fazer qualquer outra coisa corretamente. Se o programador é um falante nativo de inglês não é um problema real, já que os problemas com o seu inglês podem (e devem) ser abordados durante a revisão por pares.

Sim, é um problema sério para o produto, para a equipe e para os indivíduos.

  • Para o produto: a correção pode apresentar defeitos que só são capturados pelos clientes
  • Para a equipe: a equipe gasta tempo corrigindo a codificação malfeita em vez de criar valor
  • Para os indivíduos: a má ortografia faz você parecer estúpido e diminui sua posição profissional entre seus pares.
por 02.03.2015 / 14:38
fonte