O Stack Overflow – como a maioria das comunidades on-line que estudei – tende naturalmente a se tornar mais rigoroso com o tempo. Trata-se principalmente de um mecanismo de defesa, um sistema imunológico do tipo que uma criança desenvolve depois de entrar na escola ou na creche e ser exposta ao vasto mundo de espirros e tosses cotidianos, com o ocasional surto de meningite. Nem sempre é um processo agradável, mas, infelizmente, é necessário se o senhor quiser sobreviver.
Considere esta pergunta de dois anos atrás:
O senhor criou um novo jargão de programação?
Que termos de programação o senhor inventou que se destacaram em seu próprio círculo (ou seja, ouviu outras pessoas repetirem)? Pode ser dentro de sua própria equipe, local de trabalho ou ganhou maior popularidade na Internet.
Escreva seu termo, palavra ou frase de programação em negrito, seguido de uma explicação, citação e/ou exemplo de uso para que possamos usá-lo no contexto apropriado.
Não repita jargões comuns já arraigados na cultura de programação, como: kludge, automagically, cruft, etc. (a menos que o senhor os tenha criado).
Essa pergunta serve ao espírito de comunicação entre os programadores por meio do compartilhamento de terminologia entre eles, para nos beneficiar com sua propagação em nossas próprias equipes e ambientes.
Isso é mesmo um perguntaO senhor sabe mesmo? Quantas respostas ela tem?
Trezentas e oitenta e seis!
Uma pergunta que pede 386 “respostas” diferentes não é uma pergunta de fato. É uma pesquisa de opinião, uma enquete, uma lista de X. Suponho que o senhor poderia argumentar que a leitura de todas essas respostas o ensinaria alguma coisa sobre programação, mas ficou bem claro que a maior parte das respostas era muito mais sobre risadas e GTKY (Getting to Know You) do que sobre aprendizado. É por isso que ele acabou sendo excluído por membros experientes da comunidade do Stack Overflow. Embora seja um pouco limítrofe em termos de aprendizado, e eu não pessoalmente votou para excluí-lo, tendo a concordar que ele foi excluído corretamente. Embora as opiniões variem.
Não vou aborrecer o senhor com toda a história, nossa chamada “guerra contra a diversão”, e a problemas com a popularidade. Em última análise, O Stack Overflow é uma faculdade, não uma fraternidade. Todo o conteúdo do site deve existir para atender à missão de aprendizado em detrimento do entretenimento, mesmo que isso signifique tomar decisões difíceis sobre a remoção de algumas perguntas e respostas que não atendam a essas metas, mais ou menos 10%.
Em termos de cultura de programadores, no entanto, há um precedente na forma de O arquivo de jargões. Infelizmente, não temos um bom lugar designado para as perguntas excluídas “muito divertidas”, mas todo o conteúdo do Stack Exchange está licenciado sob a Creative Commons para sempre. Isso significa que, com a devida atribuição, podemos dar a ele um lugar permanente em nossos próprios blogs. Foi o que fiz. Reuni os 30 principais jargões de programação do Stack Overflow abaixo, de acordo com o julgamento da comunidade do Stack Overflow. Aproveite.
1. Condições de Yoda
Usando if(constant == variable)
em vez de if(variable == constant)
, como if(4 == foo)
. Porque é como dizer “se azul é o céu” ou “se alto é o homem”.
2. Manuseio de exceções de Pokémon
Para quando o senhor tem que pegar todos eles.
try {
}
catch (Exception ex) {
// Gotcha!
}
3. Suportes egípcios
O senhor conhece o estilo de colchetes em que a chave de abertura vai para o final da linha atual, por exemplo, isto?
if (a == b) {
printf("hello");
}
Costumávamos nos referir a esse estilo de colchetes como “colchetes egípcios”. Por quê? Compare a posição dos colchetes com as mãos na figura. (Esse estilo de colchetes é usado no livro de Kernighan e Ritchie A linguagem de programação Cpor isso é conhecido por muitos como estilo K&R).
4. Relatório Smug
Um bug enviado por um usuário que acha que sabe muito mais sobre o design do sistema do que realmente sabe. Repleto de detalhes técnicos irrelevantes e uma ou mais sugestões (sempre erradas) sobre o que ele acha que está causando o problema e como devemos corrigi-lo.
Também relacionado a Drug Report (relatório tão incompreensível que quem o enviou deve ter fumado crack), Chug Report (onde se acredita que o remetente bebeu demais) e Shrug Report (relatório de bug sem mensagem de erro ou etapas de reprodução e apenas uma descrição vaga do problema. Geralmente contém a frase “não funciona”).
5. Um pato
Um recurso adicionado sem outra razão a não ser chamar a atenção da gerência e ser removido, evitando assim mudanças desnecessárias em outros aspectos do produto.
Não sei se realmente inventei esse termo ou não, mas certamente não sou o criador da história que o gerou.
Isso começou como uma parte da tradição corporativa da Interplay. Era bem sabido que os produtores (um cargo na indústria de jogos, mais ou menos equivalente aos PMs) tinham que fazer uma mudança em tudo o que era feito. A suposição era de que, inconscientemente, eles sentiam que, se não o fizessem, não estariam agregando valor.
O artista que trabalhava nas animações da rainha do Battle Chess estava ciente dessa tendência e apresentou uma solução inovadora. Ele fez as animações para a rainha da maneira que achava que seria melhor, com um acréscimo: deu à rainha um pato de estimação. Ele animou esse pato em todas as animações da rainha, fazendo com que ele batesse as asas nos cantos. Ele também tomou muito cuidado para garantir que ele nunca se sobrepusesse à animação “real”.
Por fim, chegou a hora de o produtor revisar o conjunto de animações da rainha. O produtor se sentou e assistiu a todas as animações. Quando elas terminaram, ele se virou para o artista e disse, “Está ótimo. Só uma coisa: o senhor precisa se livrar do pato”.
6. Refatoração
O processo de pegar um trecho de código bem projetado e, por meio de uma série de pequenas alterações reversíveis, torná-lo completamente impossível de ser mantido por qualquer pessoa, exceto o próprio usuário.
7. Stringly Typed
Uma variação de fortemente tipado. Usado para descrever uma implementação que se baseia desnecessariamente em strings quando o programador & estão disponíveis opções de refatoração amigáveis.
Por exemplo:
- Parâmetros de método que usam strings quando outros tipos mais apropriados deveriam ser usados.
- Na ocasião em que uma string é necessária em uma chamada de método (por exemplo, serviço de rede), a string é então passada e usada em todo o restante do gráfico de chamadas sem antes convertê-la em uma representação interna mais adequada (por exemplo, analisá-la e criar um enum, e então o senhor terá uma tipagem forte em todo o restante da sua base de código).
- Passagem de mensagens sem usar mensagens tipadas etc.
O código tipado de forma excessivamente estrita geralmente é difícil de entender e detona no tempo de execução com erros que o compilador normalmente encontraria.
8. Heisenbug
desconhecido
Um bug de computador que desaparece ou altera suas características quando é feita uma tentativa de estudá-lo. (Wikipedia)
9. Decoração de tipo de documento
Quando os web designers adicionam uma declaração de doctype, mas não se preocupam em escrever uma marcação válida.
<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>
10. Jimmy
Um nome generalizado para o desenvolvedor sem noção/novo.
Descoberto quando estávamos desenvolvendo um componente de estrutura que exigia um conhecimento mínimo de como ele funcionava para os outros desenvolvedores. Sempre formulávamos nossas perguntas da seguinte forma: “E se o senhor se esquecer de atualizar o atributo?”
Isso deu origem ao termo: “Jimmy-proof” (à prova de Jimmy) quando se refere a um código de estrutura bem projetado.
11. Higgs-Bugson
Um bug hipotético que se prevê existir com base em um pequeno número de entradas de log de eventos possivelmente relacionadas e relatos vagos e anedóticos de usuários, mas que é difícil (se não impossível) reproduzir em um computador de desenvolvimento porque não se sabe realmente se ele existe e, se existe, o que o está causando. (veja Higgs-Boson)
12. Nopping
Estou escrevendo um romance de ficção científica do ponto de vista de uma IA, e sua linguagem interna contém muitos jargões de programação. Um dos termos mais generalizáveis é “nopping”, que vem do assembler NOP para “no-operation” (sem operação). É semelhante a “cochilo”, mas não implica em sono, apenas em ficar sem fazer nada. “Stanislav ficou sentado olhando o protetor de tela e cochilou por um tempo.”
13. Unicorny
Um adjetivo para descrever um recurso que está tão no início dos estágios de planejamento que poderia muito bem ser imaginário. Pegamos esse adjetivo de Yehuda Katz, que o usou em sua palestra de encerramento na edição do ano passado do Windy City Rails para descrever alguns dos próximos recursos do Rails.
14. Código Baklava
Código com muitas camadas.
Baklava é uma massa deliciosa feita com muitas camadas finas de massa filo. Embora as camadas finas sejam boas para uma massa, as camadas finas de software não agregam muito valor, especialmente quando o senhor tem muitas dessas camadas empilhadas umas sobre as outras. Cada camada tem que ser empurrada para a sua pilha mental à medida que o senhor mergulha no código. Além disso, as camadas de massa filo são permeáveis, permitindo que o mel seja absorvido. Mas as abstrações de software são melhores quando não vazam. Quando o senhor empilha uma camada sobre a outra no software, as camadas estão fadadas a vazar.
15. Hindenbug
Um bug catastrófico que destrói dados. “Oh, a humanidade!”
Também relacionado a Counterbug (um bug que o senhor apresenta quando é apresentado a um bug causado pela pessoa que apresenta o bug) e Bloombug (um bug que acidentalmente gera dinheiro).
16. Desenvolvimento orientado pelo medo
Quando o gerenciamento de projetos adiciona mais pressão (demite alguém, antecipa prazos, subtrai recursos do projeto etc.).
17. Código Hydra
Código que não pode ser corrigido. Como o Hidra da lendaa cada nova correção, o senhor introduz dois novos bugs. Ele deve ser reescrito.
18. Recurso da Common Law
anônimo
Um bug no aplicativo que existe há tanto tempo que agora faz parte da funcionalidade esperada, e o suporte ao usuário é necessário para corrigi-lo.
19. Bug do monstro de Loch Ness
Comecei a usar o bug do Monstro do Lago Ness para qualquer coisa que não possa ser reproduzida ou que só tenha sido vista por uma pessoa. Estou ouvindo muitas pessoas no escritório dizerem isso agora. (Possíveis alternativas: Bugfoot, Nessiebug).
20. Comentários do Ninja
Também conhecido como comentários invisíveis, comentários secretosou sem comentários.
21. Convenção de nomenclatura dos Smurfs
Quando quase todas as classes têm o mesmo prefixo. Ou seja, quando um usuário clica no botão, um SmurfAccountView
passa um SmurfAccountDTO
para o SmurfAccountController
. Os SmurfID
é usado para buscar um SmurfOrderHistory
que é passado para o SmurfHistoryMatch
antes de ser encaminhado para o SmurfHistoryReviewView
ou para SmurfHistoryReportingView
. Se um SmurfErrorEvent
ocorrer, ele será registrado pelo SmurfErrorLogger
para ${app}/smurf/log/smurf/smurflog.log
22. Protodução
Um protótipo que acaba em produção. Ouvi isso de um técnico do laboratório Fermi. Ele disse que não criou o termo, mas que o ouviu ser usado várias vezes no Fermi.
23. Rubber Ducking
Às vezes, o senhor só precisa falar sobre um problema. Eu costumava ir até meu chefe e falar sobre algo, ele ouvia e depois eu respondia à minha própria pergunta e saía sem que ele dissesse nada. Li sobre uma pessoa que colocou um pato de borracha em seu monitor para poder falar com ele, portanto, rubberducking é falar para resolver um problema.
24. Banana Banana Banana
Texto de espaço reservado que indica que a documentação está em andamento ou ainda não foi concluída. Usado principalmente porque o FxCop reclama quando uma função pública não tem documentação.
/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()
Outros jargões relacionados a alimentos: Combustível de programador (Mountain Dew, café, Mate, qualquer coisa que o deixe bem cafeinado), Hot Potato (Http e Https, respectivamente. Mesmo número de sílabas, mas mais divertido de dizer), Cake (o bolo noob do Marty quebrou a construção), Chunky Salsa (baseado no regra do chunky salsa(em inglês, Chunky Salsa Rule, um único erro crítico ou bug que torna todo um sistema inutilizável, especialmente em um ambiente de produção).
25. Bicrement
Adição de 2 a uma variável.
26. Falha na Realidade 101
O programa (ou, mais provavelmente, o recurso de um programa) faz exatamente o que foi solicitado, mas quando é implementado, descobre-se que o problema foi mal compreendido e ele é basicamente inútil.
27. Bug da namorada louca
Quando o senhor vê algo estranho acontecendo, mas o software lhe diz que está tudo bem.
28. Megamoth
Significa MEGA MOnolithic meTHod. Geralmente contido em um Objeto de Deuse geralmente se estende por mais de duas telas de altura. Megamoths de tamanho maior que 2k LOC foram avistados. Cuidado com o MEGAMOTH!
29. Código Hooker
Código que é problemático e causa instabilidade no aplicativo (o aplicativo “cai” com frequência). “O site caiu de novo? Sim, o Jim ainda deve ter algum código de prostituta lá dentro.”
30. Código Jenga
Quando a coisa toda desmorona depois que o senhor altera um bloco de código.
Esses são apenas os 30 principais, o que considero os candidatos mais prováveis para o reais novo jargão de programação com base nos votos positivos da comunidade, e não apenas “coisa engraçada que outro programador digitou em uma página da Web e eu me senti compelido a votar positivo por hilaridade”. Porque isso seria Reddit. Se o senhor estiver ansioso para ver ainda mais, há muitas outras respostas para ler – trezentas e cinquenta e seis, para ser mais preciso. Greg Hewgill, usuário de longa data do Stack Overflow, mantém um arquivo de perguntas antigas excluídas do Stack Overflow, mas essa ainda não chegou lá. Enquanto isso, tente Impressora Stackou, se o senhor tiver os 10 mil representantes necessários no Stack Overflow, poderá ver a versão completa pergunta excluída suavemente no site.
* Mas o senhor não gosta disso também muito. Estaremos de olho no senhor.
[advertisement] Qual é o próximo passo da carreira do senhor? Carreiras no Stack Overflow tem as melhores listas de empregos de grandes empresas, quer o senhor esteja procurando oportunidades em uma startup ou na Fortune 500. O senhor pode pesquisar em nosso anúncios de emprego ou criar um perfil e deixe que os empregadores encontrem o senhor. |