Você realmente escreve 'código limpo'? [fechadas]

54

Eu vi alguns programadores ajustando seu código repetidamente, não apenas para fazê-lo 'funcionar bem', mas também para 'parecer bom'.

Na IMO, 'código limpo' é na verdade um elogio, indicando que seu código é elegante, perfeitamente compreensível e sustentável. E a diferença surge quando você precisa escolher entre um código esteticamente atraente e um código estressante de se olhar.

Então, quantos de vocês realmente escrevem 'código limpo'? É uma boa prática? Quais são os outros benefícios ou desvantagens disso?

ykombinator
fonte
Em todas as minhas tentativas de escrever código "limpo" de acordo com princípios bem estabelecidos, nunca achei realmente fácil manter passado uma certa escala baseada apenas nessa premissa. Muito mais relevante foi a confiabilidade e o quão bem testado e adequado para a sua finalidade (que pode se relacionar tanto à implementação quanto ao design). Toda a limpeza do mundo não pode compensar a falta de qualquer uma delas, e às vezes o código mais confiável que continuo usando não é o mais limpo, enquanto o meu mais limpo nem sempre foi o mais confiável.
Portanto, acima de tudo - acima de legibilidade, beleza, SOLID, qualquer outra coisa - eu achei útil priorizar a confiabilidade e a "estabilidade" (a qualidade de ser imutável no meu livro e, além disso, sem a necessidade ou desejo de mudar mais distante). Coisas confiáveis ​​e estáveis ​​são as que duraram o teste do tempo para mim e, às vezes, não são muito limpas pelos livros de muitas pessoas (alguns dos meus códigos mais reutilizados são códigos C que datam do final dos anos 80 e início dos anos 90 que aplica coisas como hacks de quebra de bits que quase ninguém entende mais - ainda funciona de maneira confiável).

Respostas:

52

Eu diria que muitos de nós não escrevemos código limpo . E, geralmente, esse não é o nosso trabalho . Nosso trabalho como desenvolvedores de software é entregar um produto que funcione pontualmente.

Lembro-me da publicação no blog de Joel Spolsky: The Duct Tape Programmer .

Ele cita Coders at Work :

No final do dia, envie a coisa de merda! É ótimo reescrever seu código e torná-lo mais limpo e, pela terceira vez, ele será realmente bonito. Mas esse não é o ponto - você não está aqui para escrever código; você está aqui para enviar produtos. - Jamie Zawinsky

Também me lembro da resposta do blog de Robert Martin :

Assim. Seja esperto. Seja claro. Seja simples. Navio! E mantenha um pequeno rolo de fita adesiva pronto e não tenha medo de usá-lo. - Tio Bob

Se o código, um desenvolvedor escreve, passa a ser limpo E funciona (pode ser entregue), que seja bom para todos. Mas se um desenvolvedor está tentando criar código limpo e legível às custas de poder entregá-lo em tempo hábil, isso é ruim. Faça com que funcione, use fita adesiva e envie-a. Você pode refatorá-lo mais tarde e torná-lo super lindo e eficiente.

Sim, é uma boa prática escrever código limpo, mas nunca à custa de poder entregar. O benefício de entregar um produto com fita adesiva no prazo excede em muito os benefícios do código limpo que nunca foi finalizado e entregue.

Um bom pedaço de código que encontrei não está limpo. Alguns são absolutamente feios. Mas todos foram lançados e usados ​​na produção. Alguns podem dizer que não é profissional escrever código bagunçado. Discordo. O profissional é entregar um código que funcione, seja ele limpo ou confuso. O desenvolvedor deve fazer o melhor que puder, considerando o tempo alocado antes da entrega. Então, volte para limpar - isso é profissional. Felizmente, o código entregue não é fita adesiva pura e é 'suficientemente limpo'.

spong
fonte
45
Contanto que sua dívida técnica ( pt.wikipedia.org/wiki/Technical_debt ) não leve à "falência técnica" (não é possível fornecer novos recursos, corrigir uma parte quebra a outra, etc ...) e ficar de olho sobre isso, eu concordo.
Matthieu
3
@HeathLilley concordou. Só não acredito que os desenvolvedores digam que apenas código limpo deve ser escrito. Isso é falso. Código desarrumado acontece. A idéia de que os desenvolvedores devem escrever apenas códigos limpos e corretos desde o início é uma ilusão. Promovo a ideia de que sempre revisitamos e refatoramos uma vez que nossa compreensão do domínio melhora.
spong
40
O problema de "basta enviar a merda agora" é que a gerência não comprará seus motivos para refatorar mais tarde, mas se você fizer isso de forma invisível AGORA, tudo ficará bem.
Job
5
Outra ilusão é pensar que você terá tempo para limpá-lo mais tarde. Isso não vai acontecer. Você terá outras coisas para enviar. Você não deve entregar códigos confusos. E, a propósito, você também deve trabalhar em prazos, você é o técnico que sabe quanto tempo levará para escrever um código limpo. Isso não significa excesso de limpeza e ajustes por um período insano, isso significa que o tempo para refatorar antes de enviar o código deve ser levado em consideração.
Steve Chamaillard
3
"Você pode refatorá-lo mais tarde" [citação necessário]
Carl Leth
39

Você deve garantir que seu código seja muito legível, limpo e de manutenção. É o que todos os programadores devem fazer.

Mas você está falando over styling(como esse termo, melhor do código feminino ), que serve apenas o ego de seu autor.

Eu já vi muitos desenvolvedores no passado tão orgulhosos de sua criação (você sabe, como nos banheiros;)), que passaram horas limpando e polindo seu código. Alguns deles eram tão meticulosos que garantiram que os espaços em branco corretos entre os membros fossem respeitados.

É muito.

Acho esse tipo de comportamento contraproducente. Em um contexto profissional , você deve ser profissional . Você pode obter sua satisfação escrevendo códigos limpos, muito legíveis e de fácil manutenção e conversando com usuários ou colegas felizes.

user2567
fonte
13
Bem, eu polo até que o código seja claramente legível por mim. Se eu voltar duas semanas depois e tiver que descobrir o que fiz, provavelmente não está claro o suficiente para que outras pessoas possam entender facilmente.
Robert Harvey
14
O código elegante é inerentemente mais sustentável e mais fácil de ler, eu acho.
Craige
6
+1, eu já vi um CÓDIGO DE ESPAGUETE perfeitamente estilizado no passado.
22410 Jas
23
Concordo com o sentimento, mas escrevo meu código com o número correto de espaços entre os membros e fico irritado com pessoas que não o fazem. É uma coisa fácil de fazer (tornada ainda mais fácil por ferramentas automatizadas como StyleCop), e a consistência que ela oferece vale o pequeno esforço necessário.
Robert Harvey
3
@sunpech: Escreva limpo, e é muito mais fácil mantê-lo limpo.
David Thornley
24

Eu discordo da resposta aceita sobre esta questão.

Sua responsabilidade é obviamente enviada, mas geralmente você também tem a responsabilidade de enviar algo que possa ser mantido com o menor custo possível por você e por futuros desenvolvedores.

Passei períodos como um programador ou consultor de manutenção deficiente no local, que precisa entender e depurar um enorme sistema não documentado, e posso lhe dizer que projetos ruins e códigos confusos e confusos podem levar a horas ou até dias de esforço desperdiçado. Eu posso pensar em muitas situações em que N horas extras de esforço pelo desenvolvedor inicial poderiam levar a uma economia de 5N em termos de tempo.

Eu sei que há uma estatística flutuando sobre isso, mas na minha experiência em vários projetos, cada linha de código escrita é lida 5 a 20 vezes durante a extensão e manutenção.

Então, eu diria para limpar o código dentro de uma polegada de sua vida . Leva tempo, mas provavelmente é uma economia líquida de custos ao longo da vida do projeto.

Benjamin Wootton
fonte
2
Não, você limpa seu código quando e se houver tempo e orçamento, E o risco de fazê-lo é menor do que o risco de não fazê-lo. Em ambientes de produção, isso significa que muitas vezes você não aprimora o código existente para torná-lo mais bonito, apenas não é econômico, mas causa o risco de introduzir novos bugs.
jwenting
Isso também depende de em que parte do desenvolvimento de software você trabalha. Eu trabalhava para uma agência de Marketing Digital que estava mais do que feliz em repassar cobranças ao cliente se a próxima fase demorasse mais devido a problemas de base de código. Nosso esforço por mais tempo durante o desenvolvedor para corrigir os problemas existentes foi diminuído em favor do tempo estendido de desenvolvimento, igualando mais dinheiro para os negócios.
Simon Whitehead
11
Concordo com isso: você deve entregar o código, mas se não conseguir consertar / atualizar / atualizar, o que você entregou não foi um código, mas um buraco no dinheiro. Acho que as pessoas que combatem essa ideia costumam trabalhar em ambientes ruins e argumentam em um sistema que nunca experimentaram. Eu mantive o código limpo e o código não limpo e informarei que o código limpo é muito mais barato e mais rápido de manter e desenvolver.
Jdahern
21

Algum de nós compraria um carro se soubéssemos que, sob o capô, tudo é confuso e difícil de solucionar, manter ou consertar e são necessários mais recursos para rodar do que deveria?

Por que deveria ser diferente para um software?

Só porque os usuários finais não podem olhar sob o capô não significa que eles nunca saberão disso. Mais cedo ou mais tarde, ele aparecerá.

Respondendo à pergunta "Você realmente escreve 'código limpo'?" -- Oh sim.!

Sifar
fonte
Eu discordo - o software não enferruja (como Joel diz), ao contrário do interior de um carro. Você pode argumentar que, quando um sistema operacional é atualizado, o software também deve ser atualizado, mas isso é algo diferente. Além disso, eu faço um código limpo gravação, mas eu não acho que é a característica mais importante das minhas contribuições.
27512 K.Steff
18

Se, por 'código limpo', você quer dizer que eu faço o possível para garantir que o código seja o mais claro possível?

Claro que sim.

Quanto mais limpo, claro o código, mais fácil é a manutenção e, assim, economiza tempo a longo prazo. Não olhe o código limpo como vaidade; veja isso como um investimento para economizar tempo e esforço futuros.

GrandmasterB
fonte
15

Honestamente, isso depende. Gosto de como todo mundo fala sobre como "qualquer coisa menos que um código bem documentado é uma pura farsa!", Mas trabalho em uma empresa com ciclos de implantação ridículos e supervisão zero: faço o melhor que posso, mas escrevo assim quanto código é extremamente difícil escrever o código perfeito e limpo que todos os outros afirmam escrever.

Tento escrever um código que possa ser facilmente mantido por alguém que possua aproximadamente minha capacidade. Comento as partes complicadas, nomeio os nomes amigáveis ​​dos programas, variáveis ​​e classes, implanto e continuo. Não tenho tempo para fazer mais nada.

Às vezes me sinto um pouco culpado por isso, mas não muito. Você deve ver alguns dos horrores com os quais lido diariamente. Décadas de código personalizado em idiomas obscuros com zero documentação. Um dos meus colegas de trabalho se desenvolve exclusivamente no Visual Basic 6.0 e implanta binários com nomes criptografados em todo o lugar. A mulher que substituí programava exclusivamente em RPG .

É extremamente difícil para mim acreditar, na mesma porcaria horrível que vi nos meus anos como programador, que todo mundo gera apenas código limpo.

Satanicpuppy
fonte
Acordado. A maioria das pessoas não escreve códigos limpos para enviar / liberar pela primeira vez. Há fita adesiva envolvida para fazer o trabalho.
spong
2
Chega de fita adesiva! Spolsky não é deus. Ele coloca as calças em uma perna no momento, assim como nós!
Job
5
Parte do motivo pelo qual você escreve um código limpo é que é mais rápido escrever um código limpo do que um código sujo em qualquer um, exceto na linha do tempo mais curta (digamos, algumas horas). Se pensar por alguns segundos nos nomes de variáveis ​​e métodos fará com que você perca um prazo, o tempo precioso que você perderá quando você e / ou seus colegas de trabalho ficarem confusos com o seu código. Você faz o código parecer quase descartável, como você o escreverá, será usado por um tempo sem manutenção e depois retirado. Talvez na sua situação peculiar o código seja descartável. Nunca vi isso acontecer em uma década de experiência prática.
PeterAllenWebb
11
@ Peter: E em duas décadas, eu nunca vi um lugar onde cada pedaço de código estivesse limpo. Eu raramente vi um lugar onde metade estava. Onde você trabalha? NASA?
23611 Satanicpuppy
2
@Satanicpuppy Eu já vi muitos códigos sujos no meu tempo e escrevi minha parte, mas quase tudo estava desperdiçando meu tempo ou o de outra pessoa. Defendo a afirmação de que o código limpo pode realmente ser escrito MAIS RAPIDAMENTE do que o código sujo em qualquer escala de tempo maior que algumas horas.
PeterAllenWebb
7

Acho que não gosto do termo "código de garota", mas código limpo = código de manutenção. Qualquer coisa menos não é profissional.

Como regra geral, considero o próximo desenvolvedor que deve examinar minha bagunça.

Muitas vezes sou eu ... vários meses depois ... quando não me lembro como isso funciona ... e tenho ainda menos tempo para fazer uma mudança.

Heath Lilley
fonte
5

Eu tento escrever "código limpo" no sentido de Bob Martin (por exemplo, design OO). Há um grande valor na escrita de código limpo. É muito mais sustentável.

Então deixei o ReSharper torná-lo um "código bonito" para mim (por exemplo, alinhamento, quebras de linha etc.). Há um bom valor ao escrever um código bonito. Mas há retornos decrescentes. Alguma pré-certificação torna um pouco mais sustentável devido à facilidade de leitura.

Se você acha que é necessário alinhar grandes blocos de código para torná-lo legível, então o problema é seu enorme bloco de código! É muito grande. Eu vejo muitos exemplos de pessoas que se esforçam ao máximo para fingir algum código mal projetado.

Se eu não tivesse o ReSharper, ainda assim teria um código limpo, mas não seria tão bonito.

Eu não acho que deveria gastar mais do que ~ 5% do meu tempo de codificação na prettificação. O que significa que, quanto mais poderoso meu editor e mais proficiente sou com ele, mais prettificação posso fazer.

dss539
fonte
4

Parece que ninguém levanta a questão do que é do melhor interesse da sua empresa?

Freqüentemente, se não sempre, os programadores são apenas funcionários e, embora as decisões de gerenciamento possam nos frustrar, geralmente não temos todos os dados que eles possuem.

Por exemplo, digamos que a empresa tenha uma cláusula de que, se o software não estiver pronto a tempo, você não será pago (aconteceu apenas conosco, embora eu ache que recebemos o pagamento, afinal). Sim, o código limpo é importante, mas o mais importante é ter o código funcionando até o dia do pagamento!

Outro exemplo - a empresa está em uma situação financeira ruim e precisa arrecadar dinheiro. Adivinha quem se importa com a qualidade? Você pode corrigi-lo mais tarde, se for necessário, basta enviá-lo!

Um argumento pode ser "Por que devo vender e escrever códigos ruins?". Bem, por que sua empresa deveria pagar um cheque mensalmente? Escolhas, meu amigo. Se você está atrás do idealismo, tente a Free Software Foundation ; Ouvi dizer que eles estão fazendo coisas bem legais (quero dizer, este, e eu respeito a FSF e OSS).

Por outro lado, se você trabalha em um projeto em que é esperado um crescimento explosivo no uso (embora essas projeções quase nunca sejam precisas), é melhor estabelecer uma base sólida com a melhor qualidade de código necessária, pois é quase certo que a manutenção será necessária. ser o maior custo para o projeto.

Os programadores adoram código 'limpo', o que quer que isso signifique. Não podemos nem concordar com o que é limpo, mas adoramos. No entanto, às vezes isso não importa tanto quanto a usabilidade e a correção. Isso pode parecer sinônimo, mas não é - se você vê código escrito por um verdadeiro hacker Perl em 4 horas com a intenção de ser usado duas vezes e jogado fora, você reconheceria que não está limpo, mas funciona.

Então, às vezes, deixando de lado o ego, devemos fazê-lo funcionar. Observe que eu não recomendo escrever código ruim como hábito; Estou apenas apontando que pode ser necessário. A perfeição leva tempo que sua empresa pode não ter. Portanto, se o seu empregador não se importa, crie software, mas se precisar, basta escrever o código de trabalho, não se preocupe com a 'limpeza'. Não é apenas uma resposta 'tamanho único' - você deve priorizar.

K.Steff
fonte
3

Não tenho certeza de que "ter uma boa aparência" e ser "elegante, perfeitamente compreensível e sustentável" seja equivalente.

Eu tento escrever um código que seja "elegante, perfeitamente compreensível e sustentável". Refatoro meu próprio código para melhor atender a esses critérios.

Não vejo desvantagens, exceto o custo resultante no tempo.

Para que o código "pareça bom", existem muitas ferramentas automatizadas que recuam e espaçam adequadamente tudo o que você deseja.

back2dos
fonte
2
Isso me deixa ainda mais irritado quando vejo código mal formatado. A pessoa que a escreveu poderia ter usado apenas uma dessas ferramentas para fazer isso por elas. Também ocorre com mais frequência ao misturar guias e espaços para criar uma bagunça profana.
Jsternberg
3

Muita coisa nunca é boa.

No entanto, uma coisa importante a ter em mente com o código "impuro" é que ele pode facilmente levar a " janelas quebradas ". Se o código estiver muito mal formatado, acho que muitas pessoas novas na base de código podem se sentir menos inclinadas a fazer um bom trabalho com manutenção e evolução, causando uma espiral descendente que pode afetar a condição de trabalho do software.

Portanto, manter um certo nível de limpeza no código é benéfico para mais do que apenas seus colegas desenvolvedores. Não gaste muito tempo com isso (~ 5% foi mencionado). Aprenda a usar as ferramentas do seu ofício para automatizar tarefas manuais (neste caso, formatação de código). Assuma a responsabilidade pelo que faz e sempre faça o que achar mais benéfico para sua empresa / clientes / usuários.

Per Noalt
fonte
3

Esta é uma citação de Clean Code, de Bob Martin:

Para levar esse ponto adiante, e se você fosse médico e tivesse um paciente que exigisse que você parasse toda a lavagem boba das mãos em preparação para a cirurgia, porque estava demorando muito? Claramente, o paciente é o chefe; e, no entanto, o médico deve se recusar absolutamente a cumprir. Por quê? Porque o médico sabe mais do que o paciente sobre os riscos de doenças e infecções. Seria pouco profissional (não importa como criminoso) o médico cumprir com o paciente.

Da mesma forma, não é profissional que os programadores se curvem à vontade dos gerentes que não entendem os riscos de fazer bagunça.

Tulains Córdova
fonte
2

Eu acho que "código limpo" deve ser tão limpo ou mais limpo do que como você costumava escrever nos seus exames de física / engenharia / matemática. Se estiver muito bagunçado, o aluno não entenderá o seu trabalho e provavelmente o marcará errado, mesmo que esteja certo.

chiurox
fonte
2

Eu gosto que o código seja legível, mas o mais importante é a consistência. Para mim, isso significa consistência com convenções de nomenclatura e espaçamento entre funções, parênteses na mesma linha ou na próxima linha da instrução if, etc.

Claro, há momentos em que alguém programa algo com um estilo de código consistente e isso ainda me deixa louco. Especialmente código que não "respira". Por exemplo:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Bem ... Parece pior com os métodos Objective-C, e com muitas instruções if aninhadas e linhas com muito mais de 80 caracteres. Mas ainda me irrita :)

vedosidade
fonte
2

Eu me esforço muito para limpar o código. Eu acho que ajuda muito os bugs que se destacam.

Não concordo com o conceito de "enviar a merda agora", porque o código limpo é um investimento para o futuro. Também muitos softwares são enviados com muitos bugs. Resolver um bug na minha opinião é melhor do que implementar um novo recurso.

Além disso, se você olhar para as estimativas de produtividade do programador , não acho que tenha uma pontuação muito ruim. Escrever código limpo é um hábito, e quanto mais experiência como programador, mais eficiente ele se torna. Se alguém nunca tentar, obviamente, nunca obterá experiência com isso.

Outro ponto a ser levado em consideração é que a maior parte do tempo do desenvolvedor é dedicada à leitura do código; portanto, o código legível reduz bastante o tempo gasto na leitura. Entender algoritmos não documentados, por exemplo, pode ser caro e convidar novos erros.

Uma coisa que eu definitivamente sinto falta e gostaria de ter um dia é um formatador de código automático que eu possa adaptar ao meu estilo, que realmente me pouparia algum tempo, especialmente ao ler o código de outras pessoas.

A codificação limpa tem um link para o perfeccionismo, que corre o risco de nunca se materializar, mas acho que isso é principalmente um problema quando você começa, porque investe mais tarde e reutiliza seus próprios pedaços de código elegantes, combinados com sua experiência , envelhecendo, você será muito produtivo e muito menos assombrado por bugs do que os codificadores confusos.

Este é um pedaço de código que demonstra meu estilo de codificação.

user20416
fonte
1

Apenas evite "código de vaidade". Existem muitos desenvolvedores por aí que fazem coisas puramente por vaidade (ou devido a um TOC) e nada mais. Minha calcinha realmente se torce com essas pessoas.

ElGringoGrande
fonte
Como comentários de ala ou (pior) caixa, digamos?
David Thornley
1

Escrevo código que tenta resolver o problema em questão da maneira mais eficiente e teoricamente 'elegante'. Nesse sentido, apenas ele é limpo. Se isso for "bonito" quando eu terminar, que assim seja.

O que descobri em minhas experiências limitadas é que, quando as pessoas reclamam de 'código limpo', a feiúra geralmente é resultado de uma solução terrível, e não de uma convenção de codificação.

Kurtis
fonte
1

Eu diria que faço um esforço para escrever um código mais limpo, mas isso pode mudar devido a restrições de tempo ou se estou trabalhando em algo difícil. Ele tende a ficar confuso ao se concentrar em fazê-lo funcionar. Então eu voltarei e limpei enquanto reviso. Se você retornar ao código e precisar gastar muito tempo atualizando sua memória, não comentou o suficiente.

O código limpo é bom, mas como todo o resto, ele precisa estar limpo o suficiente. Recuar 5 linhas de código 4 espaços e uma linha 5 espaços não aumenta a dificuldade de leitura.

JeffO
fonte
1

Eu acho que depende do que você está fazendo. Se estou escrevendo um aplicativo de prova de conceito, basicamente estou codificando como cowboy e não olhando para trás. Se estou trabalhando em um aplicativo em que realmente vou trabalhar por um tempo, certifique-se de codificá-lo suficientemente bem e torná-lo compreensível daqui a um mês.

Eu acho que estilizar seu código é um pouco duvidoso. Como já foi dito acima, seu trabalho é fabricar um produto, não um código formatado, mas eu diria que pelo menos um deve seguir um estilo definido de comentar e codificar. Eu odiaria ver metade das variáveis ​​camel cased e a outra metade húngara.

Mas também depende do que você quer dizer com 'código limpo'.

user7007
fonte
0

Eu admito fazer isso; e o benefício não fica aborrecido toda vez que o vejo. Eu acho que também é mais fácil de ler e, portanto, os erros se tornam mais óbvios; mas a verdadeira razão é que não suporto código feio.

user281377
fonte
0

A refatoração do código para torná-lo elegante facilita a leitura e a manutenção. Mesmo pequenas coisas, como alinhar suas atribuições de variáveis:

int foo    = 1;
int bar    = 2;
int foobar = 3;

é mais fácil de ler do que

int foo = 1;
int bar = 2;
int foobar = 3;

o que significa que é mais fácil deslizar quando você está depurando mais tarde.

Além disso, no PHP você tem permissão para qualquer número de blocos de código aleatórios. Eu os uso para agrupar tarefas lógicas:

// do x
{
    // ...
}

// do y
{
    // ...
}

Isso adiciona uma definição clara ao código relevante.

Editar : como um bônus adicional, é fácil preceder um desses blocos de código lógico com um if (false)se você quiser pular temporariamente sobre ele.

Craige
fonte
11
Eu acho que eles já inventaram algo que faz isso - é chamado de função. Sempre que você criar um desses blocos, crie uma função. A partir daí, se você não quer executá-lo, comentar a chamada de função (em vez de colocar em um comentário sarcástico)
riwalk
11
@ stargazer712: Eu odeio as funções do php por causa da falta de namespaces definidos. Inevitavelmente, ao ler o código de outra pessoa, ela tem uma "inclusão" na parte superior, que inclui 5 outras coisas, cada uma com mais 4, e então eu tenho que fazer uma pesquisa em toda a base de código para encontrar a definição da função. Muito frustrante.
2381010 Satanicpuppy
Geralmente, esse é um código que não garante uma declaração de função. por exemplo. sem possibilidade de reutilização, cálculo / configuração de variáveis ​​de escopo local relacionadas, etc.
Craige
por outro lado, código sem possibilidade de reutilização é raro. Se você estiver escrevendo um monte de código que não pode ser reutilizado, há uma boa possibilidade de que ele possa ser aprimorado ... muito.
riwalk
-2

Acabei de escrever meu código, seguindo os padrões da empresa. Se eu quiser "embelezado", posso executá-lo através de um embelezador de código.

Muad'Dib
fonte
2
Exceto o que geralmente acontece, alguém acaba executando o processo através de um embelezador, tentando limpar o que você não conseguiu limpar.
riwalk
@ Stargazer712 que é exatamente por isso que eu não me incomodo muito além seguintes padrões da empresa
Muad'Dib
@ Maud'Dib, o problema é que o resultado é tão bom quanto o embelezador. Enquanto o espaço em branco horizontal é inteiramente sobre escopo (e, portanto, limpa muito bem), o espaço em branco vertical é geralmente sobre intenção (agrupar o que está relacionado) e limpa muito mal. Bottom line - tenha piedade de seus colegas desenvolvedores.
riwalk
@ Stargazer712 O problema é que, com exceção dos "padrões da empresa", todo o resto é inteiramente uma questão de gosto, que é subjetiva. por exemplo, eu gosto de colocar espaços em lugares onde meu colega de trabalho os odeia positivamente. Faço com que pareça agradável para mim, e isso é o máximo que posso.
Muad'Dib
11
Tenha cuidado com os "embelezadores", pois eles podem atrapalhar a fusão dos commits muito tempo (tenho experiência em primeira mão :)).
Juha Untinen