Qual a importância de um bom estilo de codificação para a decisão de contratar um programador? [fechadas]

Mesmo quando estudante, sou solicitado a revisar o código de programadores que (não) passaram no teste (crie uma lista de números de Fibonacci no Android).

Embora eu seja muito rigoroso no estilo de codificação, acabei de ler sobre o estilo "bloco" que alguém usou (leia os comentários!) .

Na minha posição, eu recomendaria não contratar um cara usando esse tipo de estilo. O código é completamente o oposto do estilo de codificação usado na minha empresa.

Ao procurar pelo estilo de codificação e como lidar com a falta dele , estou curioso sobre uma coisa: devo contratar um cara que teráproblema sério adaptar o estilo de codificação usado na empresa?

Por favor: Esta não deve ser uma discussão sobre o estilo de codificação em geral e qual é o melhor. É sobre a importância do estilo de codificação para a decisão de contratar alguém!

Mais Informações:

Eu não sou o cara que toma a decisão, apenas dou minha opinião com base no código. O cara tem que passar por uma entrevista em que nosso chefe verifica tudo o que é macio. Se ele passou por isso, ele passou no nosso pequeno teste de habilidade e é aí que às vezes me pedem para revisar o código escrito. Não estou em posição de dizer sim ou não. Eu só quero saber o quão importante o estilo de codificação deve ser para minha análise ...

Como você sabe que ele terá problemas para se adaptar? Só porque eles usam um estilo de codificação diferente? Isso é bastante presunçoso. Sou contratado há muito tempo e, independentemente do estilo de codificação usado, você se adapta. Pode levar algum tempo, mas os hábitos se formam rapidamente.

Espero que, ao codificar o estilo, você não se refira apenas ao recuo e ao layout do código. Isso é facilmente resolvido usando um formatador de código e integrando-o ao seu sistema de controle de versão.

Tomando como estilo de codificação significam coisas como nomeação, ordenação geral, separação de unidades e tudo mais que lida com legibilidade e manutenção, a coisa mais importante sobre o estilo de codificação é que você possui um. Não qual. Não ter um estilo de codificação é uma bandeira vermelha definitiva.

A segunda coisa mais importante sobre o estilo de codificação que alguém usa é que eles o usam de maneira consistente. Quando alguém parece usar um estilo de codificação, mas freqüentemente "peca" contra isso, isso é outra bandeira vermelha definitiva.

Tendo programado em centenas de projetos diferentes para quase uma centena de clientes diferentes, deixe-me enfatizar um ponto.

O estilo de codificação (e a discussão sobre o estilo de codificação) é uma completa perda de tempo.

Deixe isso para trás.

Eu li muito código de muitos programadores diferentes. (Suponha uma equipe mediana de 5 e 100 equipes diferentes. São 500 colegas de trabalho.) Estilo não importa.

Eu vi um código bonito, mas patologicamente errado.

[Existe um limite. Ofuscação intencional é motivo para rescisão. Além disso, o estilo é uma perda de tempo.]

O estilo de codificação é a "fronteira final"

Se você resolveu todos os problemas do desenvolvimento de software; se você pode produzir código sem erros mais ou menos instantaneamente; se o seu nível de qualidade for tão alto, você não terá mais uma fila de correção de erros; se sua usabilidade é tão fabulosa, você não tem mais um suporte técnico; se você consegue otimizar impiedosamente até o ponto em que não possui um farm de servidores, mas executa a empresa a partir de um iPad ...

Quando não há mais nada para corrigir, você pode finalmente se concentrar no estilo de codificação.

Até então, existem inúmeras questões que são maiores e mais valiosas que o estilo.

Julgar os programadores com base no estilo de codificação é 50% snobbery e 50% insegurança.

Eu gosto que meu código pareça arrumado e limpo, e parece que o cara que o OP digitou no link também. Nosso código não parece o mesmo, mas nós dois usamos um estilo que nos ajuda a entender o código quando voltamos a ele. Não tive absolutamente nenhum problema em entender o código dele e duvido que o OP também o tenha feito. O "conselho" do estilo de codificação nada mais é do que um tiro fácil e barato, onde você pode transmitir sua imensa sabedoria a respeito de por que os aparelhos devem estar na próxima linha. Não importa nada. O que torna o código difícil de ler é:

• convenções de nomenclatura insanas (ou falta delas) que não descrevem o que elas representam.
• fluxo de programa insano que dificulta dizer o que está acontecendo (vá, tente / pegue com a lógica de negócios etc.).
• funções insanamente longas que fazem mais coisas do que o cérebro pode acompanhar.

Tenho problemas para imaginar qualquer código que não fez nenhuma das coisas listadas acima, mas ainda era difícil de ler, especialmente com uma ferramenta como o Style Cop.

É ridículo ter o formato do código um fator ao decidir contratar alguém.

1. Existem muitos fatores mais importantes a serem considerados.
2. A maioria dos desenvolvedores pode adaptar seu estilo.
3. Se o formato for tão importante, use um reformatador de código e um verificador de cotão.

Não está contratando um bom desenvolvedor, porque ele não adiciona um espaço depois que uma vírgula é boba.

Suponho que você tenha um estilo de formatação oficial na empresa.

Torne extremamente fácil reformatar qualquer fonte para o estilo oficial e, de preferência, faça isso acontecer automaticamente sempre que o arquivo de origem for salvo.

Qualquer programador que se preze vai adorar isso, pois garante uma qualidade mais alta, minimizando as diferenças de consolidação.

Use StyleCop

Se você estiver usando o Visual Studio, sempre poderá forçar as regras do StyleCop com sua compilação, o que garantirá que seu código seja pelo menos legível.

Rejeito o código ilegível, sem dúvida o estilo não-padrão , porque se tornará muito difícil de manter no futuro - mesmo pelos próprios autores. Isso já foi provado muitas vezes no passado.

Formatação de código integrado do CVS = solução ideal

Seria ótimo se algum CVS suportasse a formatação automática de código nos check-ins. Você acabou de definir suas prioridades de estilo, o código seria formatado antes de ser salvo. Isso tornaria obsoleto o estilo específico do desenvolvedor em termos de formatação de código. Eu posso ver o problema se alguns desenvolvedores estiverem usando caracteres de indentação diferentes. Não é tão problemático para mim olhar para código diferente (e posso reformatá-lo com facilidade e rapidez), mas o DIFF se torna mais difícil de lidar. Muitos falsos positivos na ferramenta DIFF.

Muito abaixo dos seguintes detalhes muito mais importantes:

• Team Fit
• Habilidades de resolução de problemas
• Comunicação

Os estilos de codificação podem ser aprendidos pela maioria das pessoas que têm os dois últimos listados acima.

No entanto, geralmente vejo um exemplo de código antes da entrevista final e, se o estilo de codificação estiver muito distante do que usamos, vou me concentrar nas perguntas que expõem sua capacidade de adaptação.

Desde que o estilo seja consistente e essa pessoa possa se adaptar (mudar) a outro estilo, não vejo problemas.

Se o estilo atual é diferente do que você usa, isso não significa que é ruim. Para o candidato, pode fazer sentido.

Assim como outros disseram, ter problemas para se adaptar pode ser o único problema.

Eu não diria que este é um contrato definitivo, mas é um forte argumento contra essa pessoa.

Na verdade, eu não me preocuparia com o estilo de codificação, mas com essa incapacidade de se adaptar, sendo um sintoma de um problema geral. Eu teria medo de que o candidato também ache difícil se adaptar a outros aspectos da cultura da equipe.

Se você não consegue se concentrar no uso do estilo pascal em vez do invólucro no estilo camelo, pode ter problemas em lembrar de iniciar um novo lote de café se tomar a última xícara. Esse tipo de coisa pode ser realmente prejudicial para a equipe.

(E sim, eu sou viciado em cafeína.)

Na minha opinião, um bom estilo de código é essencial para um programador trabalhar.

Ter um bom estilo de código é uma questão de desenvolvimento pessoal. É um indicador do nível que esse programador já atingiu.

A questão é se sua empresa deseja "altos profissionais" ou "altos potenciais". Se você precisa de "altos profissionais" e não há espaço para aprender e evoluir - o estilo do código é um critério de nocaute.

Se houver espaço para desenvolvimento e desenvolvimento de programadores, é melhor você se preocupar com a capacidade de aprender rápido ou pensar criativo.