Por que tanto código é assim? - página 3

Novo comentário
 
RaptorUK:

Mas isso não significa que se eles estão pedindo ajuda com sintaxe ou lógica o código não vai "... ser sintática e logicamente correto;" ?

Sim, você está certo. Mas no contexto de discutir os estilos/práticas de codificação mais (ou menos) eficazes, o aspecto mais importante é que o código seja sintática e logicamente correto, independentemente do estilo de codificação utilizado. Acho que outra maneira de dizer é que o estilo deve dar lugar ao código sintáctica e logicamente correto - a questão principal não é se o código parece bom e é facilmente legível, mas, ao contrário, se é sintáctica e logicamente correto para realizar a tarefa para a qual está escrito :)

Eu também concordo com // comentários. Nunca se pode ter muitos // comentários, tanto para refrescar a mente do programador original quanto aos detalhes das várias partes do código e para ajudar/ajudar a compreensão dos outros sobre o código pós-completamento/implementação.

 
Thirteen:

Sim, você está certo. Mas no contexto de discutir os estilos/práticas de codificação mais (ou menos) eficazes, o aspecto mais importante é que o código seja sintática e logicamente correto, independentemente do estilo de codificação utilizado. Acho que outra maneira de dizer é que o estilo deve dar lugar ao código sintáctica e logicamente correto - a questão principal não é se o código parece bom e é facilmente legível, mas, ao contrário, se é sintáctica e logicamente correto para realizar a tarefa para a qual está escrito :)

Ah OK, estou vendo o que você está dizendo . . . código belamente apresentado não tem utilidade se não funcionar . . . mas talvez seja mais fácil de consertar ?
 
RaptorUK:
Ah OK, estou vendo o que você está dizendo . . . código belamente apresentado não tem utilidade se não funcionar . . . mas talvez seja mais fácil de consertar ?
Correto. Em outras palavras, os estilos/práticas de codificação e apresentação, que são em grande parte a escolha do programador, são um meio para um fim (sendo o fim código sintática e logicamente correto) :) Quando o código pode ser facilmente lido e compreendido pelo programador (e posteriormente por outros que não escreveram o código), é muito mais fácil detectar e corrigir erros sintáticos e/ou lógicos.
 

Acho que a maioria dos estilos de codificação permite tanta legibilidade quanto o codificador quer ou precisa, eu fecho meu código quando ele está terminado e funcionando, mas é fácil abri-lo novamente com alguns espaços de linha se eu precisar compartilhá-lo ou discuti-lo. Acho que um formato de codificação deve suportar a fácil identificação de uma pulseira ausente, e a fácil identificação de pares quando há uma árvore complexa ou com múltiplos ramos. Eu nunca adotei o estilo K&R, então gostaria de ver como os codificadores do estilo K&R o fazem.

 
SDC:

Eu fecho meu código quando ele está terminado e funcionando, mas é fácil abri-lo novamente com alguns espaços de linha se eu precisar compartilhá-lo ou discuti-lo.

Por que fechá-lo de todo? Eu realmente não entendo o ponto de esmagar o código. Se você precisar abri-lo para compartilhar/discutam o que isso implica?

SDC:

Acho que um formato de codificação deve suportar a fácil identificação de uma cinta faltando, e a fácil identificação de pares quando há uma árvore complexa ou complexa com múltiplos ramos. Eu nunca adotei o estilo K&R, então eu gostaria de ver como os codificadores do estilo K&R o fazem.

Para o estilo K&R, a cinta inferior se alinha com a condição correspondente. Eu uso pessoalmente

1. Travessões consistentes

2. Para as cláusulas de declaração única, ou se devem ser amarradas e recuadas OU se devem seguir a condição sem amarras, ou seja.

if (flag) {
   i++;
}

OR

if (flag) i++;

3. Use um editor de programadores decente que combine com braçadeiras.

Os suportes correspondentes não são problema - a maioria do núcleo do linux é escrita neste estilo, e é o padrão Java. Embora eu possa ver a atração do estilo Allman como, com o estilo K&R, muitas vezes eu inseriria uma linha extra em branco após a condição para desobstruir o código. Hmm Eu poderia ser convertido :)

 
ydrol:

Por que fechá-lo de todo? Eu realmente não entendo o ponto de esmagar o código. Se você precisa abri-lo para compartilhar/discutir o que isso implica?

Para o estilo K&R, a cinta inferior se alinha com a condição correspondente. Eu uso pessoalmente

1. Travessões consistentes

2. Para as cláusulas de declaração única, ou se devem ser amarradas e recuadas OU se devem seguir a condição sem amarras, ou seja.

3. Use um editor de programadores decente que combine com braçadeiras.

Os suportes correspondentes não são problema - a maioria do núcleo do linux é escrita neste estilo, e é o padrão Java. Embora eu possa ver a atração do estilo Allman como, com o estilo K&R, muitas vezes eu inseriria uma linha extra em branco após a condição para desobstruir o código. Hmm Eu poderia ser convertido :)

Eu apenas o fecho para que ele tome menos espaço na tela. Gosto de ver o máximo dele ao mesmo tempo em que cabe na tela. Eu não preciso de um par de chaves, eu o formato de modo que se eu colocar um cursor atrás de uma chave e o correr verticalmente para cima das linhas com a tecla de seta, quando ele toca outra chave que é seu par. se eu o colocar atrás de um outro par e fizer a mesma coisa, quando ele toca um par de chaves, quando ele toca um par de chaves.

Nesta seção do código é fácil ver o terceiro par o primeiro se, o segundo par o segundo se o primeiro par o terceiro se porque o(s) par(s) atrás de cada outro se alinham verticalmente atrás de seu correspondente par se. Da mesma forma, é fácil ver quais if's não têm um outro porque cada if brace se alinha verticalmente com sua correspondente cinta de fechamento no conjunto atrás do outro. Não estou sugerindo que todos os outros formatem o código desta maneira só porque eu gosto, mas para mim, é compacto e lógico.

      if(downtrend)
      {if(High[i] < LineDownBuffer[i+1])
       {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
        }else
        {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1])
         {LineDownBuffer[i] = DeMarkerHighBuffer[i];
       }}}else
       {if(High[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
         LineUpBuffer[i] = DeMarkerLowBuffer[i];
         downtrend = false;
         uptrend = true;
      }}}else
 
SDC: Eu acho que a maioria dos estilos de codificação permite tanta legibilidade quanto o codificador quer ou precisa, eu fecho meu código quando ele está terminado e funcionando, mas é fácil abri-lo de volta com alguns espaços de linha se eu precisar compartilhá-lo ou discuti-lo. Acho que um formato de codificação deve suportar a fácil identificação de uma pulseira ausente, e a fácil identificação de pares quando há uma árvore complexa ou com múltiplos ramos. Eu nunca adotei o estilo K&R, então gostaria de ver como os codificadores do estilo K&R o fazem.

Não posso responder a isto para cada codificador usando o k&r. Honestamente, quanto mais eu olho para o seu formato, mais eu gosto dele. Se eu tivesse adotado o estilo Allman, eu definitivamente poderia me ver usando sua versão modificada. A linha de aparelhos debaixo um do outro, se livra dos aparelhos de abertura e fechamento que ocupam uma linha inteira. Você pode passar o cursor pelo i sobre o se e encontrar aparelhos em falta, sem se preocupar com convenções de tamanho de abas/indentação, modo compacto {ver a maioria de seus códigos na tela}. Portanto, sim, é muito legal, é só no primeiro olhar, porque não estou acostumado, parecia confuso. E esse é o cerne da questão aqui.

Parece que muitos codificadores americanos adotam o [KnR & Allman] onde, como o estilo dos brancos, parece popular entre os europeus. O Whitesmith é também o estilo Default para Mt4. Agora não há nada de errado com nenhum destes estilos, é que quando estou ajudando alguém, tenho que continuar me lembrando de ignorar meu estilo K&R e pensar mais Whitesmith. Isso ou usar um formatador de código.

O porquê de alguém querer escrever "complexo se outras árvores" está além de mim. Quando alguém deixa todo o White_Space e formatação dentro de um complexo if_nest, parece que estava tentando projetar uma Cobra | Spaghetti | ZigZag através da página. A primeira se começa na linha 1 e termina na linha 300, cerca de 150 ou %50 dessas linhas estão sendo seguradas por aparelho. Ao invés do "complexo se mais árvores", por que não apenas criar uma função. Então deixe que a linha_1 realmente termine na linha_1 com if( false ){ return; }.

 

Obrigado ubzen Estou feliz que alguém goste do meu formato rs. Eu uso muito, provavelmente porque quando comecei a codificar alguém me disse se mais alguém faz código rápido, então eu tenho o hábito de fazer dessa maneira.

 
SDC:

Obrigado ubzen Estou feliz que alguém goste do meu formato rs. Eu uso muito, provavelmente porque quando comecei a codificar alguém me disse se mais alguém faz código rápido, então eu tenho o hábito de fazer dessa maneira.

Não é nada pessoal


É em momentos como este que teria sido bom ter um padrão formal aplicado que todos trabalham para... ... então todos estaríamos fazendo a mesma coisa e todos gostaríamos do seu código. E antes que você pergunte, não, vou me ater ao meu estilo Whitesmiths . . . pelo menos sei como chamá-lo agora, obrigado ubzen

 
SDC e RaptorUK são bem-vindos. A codificação torna um tópico muito mais fácil de discutir do que Winning_EA. :)
1234
Novo comentário