A formatação do código tem que importar?

5

ATUALIZAÇÃO: uma questão surgiria de coisas que não são estritamente definidas por um formatador, como linhas vazias consecutivas, etc., que se perderiam no processo (reformatação de local para servidor para local) que incomodaria as pessoas (eu também :)

Estou acostumado a adotar algum formatador de código compartilhado, então minha pergunta não é sobre "devo enviar para isso?"

Eu me pergunto se isso (formatação de código) tem que importar em tudo? Não é possível ter o seu repositório armazenando seus compromissos em alguma formatação "padrão"? Você nunca conseguiria ver como esse estilo se parece, porque toda vez que você fizer o checkout de todas as fontes, você será salvo no disco rígido depois de ser reformatado usando o SEU formatador. Também toda vez que você navega pelo repositório, seu cliente lhe mostrará a fonte reformatada usando o SEU formatador. Também todos os diffs seriam feitos após a reformatação usando o formatador YOUR.

Isso é possível? (Por exemplo, plugins de clientes, configuração de repositórios, etc.)

    
por Jaroslav Záruba 01.11.2014 / 23:03
fonte

3 respostas

4

Tecnicamente, o principal problema que vejo é com números de linha e depuração. Se você reformatar o código, o código pode acabar em linhas diferentes, tornando muito mais difícil fazer sentido de stacktraces e tal. Referir-se também ao código em geral seria muito mais difícil, se seus colegas virem linhas diferentes de você.

No contexto de colaboração, acho que a reconhecibilidade do código é importante. Se eu olhar o mesmo código na tela de um colega, seria muito mais difícil colaborar se eu não reconhecer o código facilmente.

    
por 02.11.2014 / 19:10
fonte
3

Há uma excelente ferramenta uncrustify que usa uma descrição da formatação do código-fonte de um arquivo de configuração e gera uma saída arquivo formatado como por especificação no arquivo de configuração. No entanto, existem alguns problemas com essa abordagem, os mais óbvios e importantes são:

  1. O arquivo armazenado no repositório será diferente da visualização do seu arquivo, dificultando muito a visualização dos diffs.

  2. Será muito mais difícil manter as alterações de espaço em branco separadas dos commits importantes.

Tenho certeza de que há mais.

    
por 01.11.2014 / 23:11
fonte
3

Não ter regras não é liberdade, é apenas caos. Como escrever um livro sobre linguagem de programação sem nenhum padrão de codificação? Você consegue imaginar cada livro com formatação completamente diferente?

Eu tenho preferências pessoais sobre como o código deve ser, mas minha personalidade não é realmente importante quando eu trabalho em equipe. A colaboração é importante e os padrões de codificação tornam possível , não apenas mais fácil.

Is this possible to do? (E.g. client plugins, repository configuration, etc.)

Sim, mas com pior desempenho, bugs e fase de configuração adicional. Eu tenho o suficiente de configuração e plugins, graças ao Maven, então é melhor ficar com boa e velha disciplina.

No entanto, há uma ideia sobre como armazenar um programa não como seu código-fonte, mas como é a árvore de sintaxe. Como ASTs que não reconhecem a linguagem e outras coisas.

Atualização: nos comentários.

Eu vejo e entendo seu argumento, mas ainda acredito que minhas preocupações sejam verdadeiras.

Imagine que você tenha esses plug-ins mágicos que abstraem a formatação. Você se junta e codifica com outras pessoas sem saber sobre suas preferências, e é tudo arco-íris duplo no céu =)

Então, um de seus colegas lhe diz algo como: "Estou escrevendo um livro sobre programação, preciso da sua ajuda." Então ela lhe envia um manuscrito e você vê que ela foi em direção completamente oposta com não só formatação, mas até mesmo com sintaxe concreta. Imagine que ela inventou algo como CoffeeScript no topo da linguagem que você usa: palavras-chave são diferentes, construções de sintaxe mais curtas, etc. É totalmente possível quando você tem um plugin tão mágico e as pessoas o fazem (por causa da lei de Murthy, e t nenhuma piada).

Então, você não pode ajudá-la, a menos que ambos rejeitem suas preferências pessoais e usem formatação "padrão", "padrão" e sintaxe concreta. Ta-a-da-a!

Então eu afirmo:

  1. Se houver N pessoas e cada um puder ter seus próprios estilos de sintaxe e formatação concretos, eventualmente haverá N estilos diferentes.
  2. Se houver pessoas usando esses estilos diferentes, eles escreverão livros usando esses estilos diferentes ou concordarão em usar "padrão".
  3. Se você acabar usando o "padrão" para poder colaborar, por que se preocupar com a personalização?

Eu não estou insistindo em "pureza" ou algo assim. Eu trabalho com código que muitas vezes tem uma mistura de diferentes estilos de formatação. Mas isso é principalmente apenas pequenas diferenças que não afetam a linguagem. Eu estou totalmente bem com isso.

Mas eu não quero aprender uma nova língua apenas para alimentar o ego de alguém (também meu próprio, para esse assunto). Eu às vezes apenas copio e colo o código no meu mensageiro instantâneo e não quero ter nenhum plugin nele (tanto no meu quanto no destinatário, eu sei) para enviar um trecho.

Se você tem um plugin tão mágico no seu IDE, você tem que ter esses plugins em todos os lugares que você quer furar o código. Isso não é nada mais do que problemas adicionais.

Resumo: você pode fazer isso, mas não deveria. Padrões são melhores quando personalizados. As convenções são melhores que os plugins.

Atualização 2:

A pessoa da imagem A prefere colocar uma chave de abertura em uma linha separada:

while (true) // endless loop
{

Então este código pode ser armazenado em algum tipo de árvore de sintaxe e mostrado para a pessoa B, que usa o estilo egípcio. Isso pode ser feito da seguinte forma:

while (true) /* endless loop */ {

ou mais:

// endless loop
while (true) {

E este segundo tem uma ordem diferente de fichas.

Isso mostra que nem todas as construções de sintaxe se encaixam nesse modelo. Portanto, a linguagem provavelmente deve ser restrita de várias maneiras para fornecer a capacidade de personalizar a formatação. Ainda assim, acho que é possível, já que existem linguagens de programação como Google's Blockly , que têm sintaxes concretas e "armazenadas" completamente diferentes. / p>

Aliás, o Blockly é uma prova de conceito, já que você pode personalizar o frontend de acordo com o seu gosto artístico.

    
por 02.11.2014 / 00:18
fonte