Etiqueta de código aberto

14

Comecei a trabalhar no meu primeiro projeto de código aberto no Codeplex e me deparei com um código terrível. (Eu aprendi que o C # ainda tem a instrução "goto") Eu comecei adicionando recursos que o "dono" queria e depois de explorar a base de código e ver que bagunça era (por exemplo, usando "goto") eu queria limpá-lo um pouco. Mas eu estou um pouco preocupado e é por isso que estou me voltando para todos vocês: é uma etiqueta apropriada para eu "consertar" o "código ruim" ou devo deixá-lo trabalhar em novos recursos? Como eu disse antes, sou novo em toda a cena do OSS e trabalho em um time em geral, então eu gostaria de não estragar tudo.

    
por Jetti 24.03.2011 / 13:47
fonte

7 respostas

18

Tudo bem, se você é modesto e não quebra nada. Você não pode sair por aí reformatando códigos e introduzindo bugs. Tem bons testes unitários? Se não, eu começaria a contribuir adicionando testes de unidade e depois corrigiria a estrutura mais tarde.

    
por 24.03.2011 / 13:59
fonte
13

O objetivo do código aberto é obter mais olhos em um projeto e melhorá-lo. Isso inclui melhorar o código. Dito isto, é uma boa forma de anunciar na lista o que você pretende fazer. Você pode receber algum empurrão, ou você pode receber um monte de + 1s. Essas instruções goto podem estar lá porque o autor original não conseguia pensar em uma maneira melhor de fazer o trabalho. Se você for empurrado para trás, é bom entrar em um diálogo para descobrir de onde vem a pressão. Tente não deixar que isso seja pessoal e tente resolver as preocupações.

Linha de fundo, testes de unidade falam mais alto que dogma. Se você puder provar que o código irá funcionar mal em certos casos do jeito que está agora, você receberá um sinal positivo ou o autor original entrará e consertará as coisas.

Lembre-se, no open source, a comunidade é mais importante que o código. Se não houver comunidade (tanto de usuários quanto de desenvolvedores), então não há projeto.

    
por 24.03.2011 / 14:09
fonte
6

As pessoas que são zelosamente defensivas sobre seu código geralmente não o publicam para o mundo examinar, e se o fizerem, a comunidade em torno dele não durará muito tempo. Seja diplomático, mas não se preocupe se você ferir sentimentos.

Diga-lhes apenas o que você quer fazer antes de investir muito tempo nisso. Às vezes há razões históricas para coisas que não são óbvias. A razão pela qual as vacinas são evitadas é que elas podem produzir caminhos imprevistos através do código. Consequentemente, o perigo de remover gotos é que você não percebe um dos caminhos benéficos e acidentalmente o omite do refatorador.

Por outro lado, talvez o autor original não conseguisse pensar em uma maneira mais clara de escrevê-lo no momento. É aqui que o código fala mais alto que as palavras, porque elas podem não acreditar que isso pode ser feito de forma mais clara até que você as mostre. Uma das minhas primeiras contribuições de código aberto foi uma correção de undo stack que melhorou significativamente o desempenho, mas que alguns dos desenvolvedores do núcleo disseram que soaram muito complexos quando eu descrevi isso pela primeira vez. Uma pequena amostra de código os trouxe a bordo.

Se acontecer de haver boas razões para deixá-lo, eu pediria pelo menos um comentário explicando essas razões.

    
por 25.03.2011 / 13:45
fonte
6

Falando de experiência ...

O primeiro projeto Open Source que eu contribuí, eu estava todo cheio de mijo e vinagre quando comecei também.

O que eu fiz imediatamente foi passar por vários arquivos de origem e começar a estilizar as coisas de acordo com minhas preferências pessoais, criar um patch enorme e enviá-lo.

Se você estiver trabalhando com alguém que seja "bom" (como eu era), ele rejeitará imediatamente o patch. Principalmente porque, quando você contribui para um projeto de código aberto, espera-se que você divida suas correções em partes do tamanho da mordida que tratam de um único problema. 'Removido todos os gotos' não é um bom exemplo de commit atômico. Mesmo se você dividir em commits menores e bem documentados, ele pode ser rejeitado.

O motivo é, porque o código é trabalhado por várias pessoas (com estilos diferentes) ao longo do tempo, não é realmente possível aceitar mudanças em toda a biblioteca para se adequar ao estilo de um desenvolvedor. Se a mudança de estilo pelo estilo fosse viável, todo projeto de código aberto nunca iria avançar porque o código seria constantemente editado para se adequar a diferentes estilos de desenvolvedores.

Refatorar código e adicionar funcionalidade (ou remover reprovações reprovadas) normalmente tem precedência sobre o código de 'limpeza'.

A parte mais difícil e mais gratificante de trabalhar em um projeto de código aberto é: você será perguntado por que está propondo fazer as alterações que está enviando. Se você puder dar uma boa razão, há uma chance maior de que seu patch seja enviado.

Meu conselho é fazer algumas dessas alterações em um arquivo de origem para dar uma amostra do que você está tentando fazer primeiro. Se as mudanças forem bem justificadas e aceitas, pergunte se mais mudanças como essa melhorariam a qualidade do projeto. Dessa forma, você não desperdiçará muito esforço por nada se seus patches forem rejeitados no futuro.

O desenvolvimento de código aberto é mais do que escrever código. Você está trabalhando para construir uma relação de confiança porque os gatekeepers (desenvolvedores que controlam o acesso por push) farão o que for necessário para proteger a integridade do projeto. À medida que você enviar mais patches, o gatekeeper perceberá melhor seu estilo e você não terá que justificar suas alterações.

É um processo que leva tempo, mas é muito gratificante. Não apenas você aprenderá muito com a capacidade de analisar e criticar o código de outras pessoas, mas também será criticado em seu próprio estilo.

Antes de perder muito tempo tentando "corrigir a injustiça dos erros do estilo de codificação do outro", pergunte-se:

Are the changes you're proposing based on adding value to the project or are they based on your own internal stylistic religion.

Existe um lote de religião no Stack Overflow (e sites relacionados do Stack Exchange). Eu quero dizer um lote . As pessoas pensam e falam sobre estilo indefinidamente, como se quanto mais você fala sobre isso, mais perto você fica do estilo de codificação 'perfeito, ideal, indestrutível, infalível'. Eu falo muito sobre isso principalmente porque é divertido.

No mundo do código aberto, o estilo não é tão importante. A função é .

Nota: Todo este conselho assume que o seu gatekeeper é um programador razoável e talentoso. Se ele (a) for, considere-se sortudo por não ter ficado preso a um dos b @ & xs whiny cuja única preocupação é proteger seu 'bebê'. Eles fazem existem na natureza, então não se surpreenda se você encontrar um.

    
por 25.03.2011 / 15:40
fonte
1

Qualidade > Etiqueta

Na minha opinião, você não deve se preocupar em editar o código de outras pessoas assim que descobrir que ele tem baixa qualidade. Para obter uma boa qualidade de software, você simplesmente precisa se preocupar com um código limpo. Eu não vejo nenhum problema em cometer melhorias no código de outras pessoas que outras pessoas devem estar cientes e grato que existem codificadores que trabalham em seu código.

    
por 24.03.2011 / 13:53
fonte
0

Se você pudesse descobrir uma maneira melhor de resolver o problema sem usar "goto", sugiro que vá em frente. Um pouco de esforço para tornar o código melhor hoje pode poupar muito mais esforço no futuro.

A comunicação com o autor original também é uma boa ideia.

    
por 24.03.2011 / 16:12
fonte
0

Não há nada de errado com goto . Veja o código de montagem - muitos giros (saltos e ramificações) por todo o lugar.

A razão pela qual goto tem um nome ruim nos dias de hoje é por causa do artigo de Dijkstra Ir para declaração considerada prejudicial que apontou a declaração goto como algo muito ruim.

Note que isso foi há 50 anos, onde a engenharia de software ainda não era nomeada, e a maioria das linguagens de programação eram essencialmente abstrações da máquina subjacente, assim como a linguagem de máquina continha, assim como elas. Você pode tentar programar alguns no Microsoft Basic (o original, no Apple] [ou no Commodore 64) para ter uma idéia de como essa mentalidade era.

O que Dijkstra estava argumentando era que, para manter as coisas simples, não pularia por todos os lados, mas sim manter um caminho de programa mais simples com um final comum. Por exemplo. um retorno de um método. Em outras palavras - apenas saltos locais, não globais.

Este foi um passo para introduzir coisas como chamadas de método com argumentos, modularização de código, pacotes, etc., todos introduzidos para dominar a complexidade do desenvolvimento de software. A declaração goto foi apenas o primeiro espectador naquela guerra.

    
por 11.02.2017 / 13:35
fonte