ti-enxame.com

Aparelhos devem aparecer em sua própria linha?

O aparelho deve estar na sua própria linha ou não? O que você acha disso?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

ou deveria ser

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

ou mesmo

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Por favor, seja construtivo! Explique por que, compartilhe experiências, faça backup com fatos e referências.

284
Tamara Wijsman

Quando eu era estudante, costumava colocar chaves na mesma linha, para que houvesse menos linhas e o código fosse impresso em menos páginas. Observar um único caractere de colchete impresso como a única coisa em uma linha é irritante. (ambiente, desperdício de papel)

Porém, ao codificar aplicativos grandes, permitir que algumas linhas com apenas chaves sejam acessíveis, considerando o sentimento de "agrupamento" que ele proporciona.

Seja qual for o estilo escolhido, seja consistente para que não se torne uma sobrecarga para o seu próprio cérebro processar vários estilos em partes do código relacionadas. Em diferentes cenários (como acima), eu diria que não há problema em usar estilos diferentes, é mais fácil alternar o contexto em um nível alto.

90
dbza

Você nunca deve fazer o terceiro método.

Poupar nas chaves pode poupar algumas pressionamentos de tecla na primeira vez, mas o próximo codificador que vem junto adiciona algo à sua cláusula else sem perceber que o bloco está faltando chaves, vai causar muita dor.

Escreva seu código para outras pessoas.

251
rhettg

Por um longo tempo, argumentei que eles tinham igual valor, mais ou menos muito próximo de igual que o ganho possível ao fazer a escolha certa estava muito, muito abaixo do custo da discussão sobre isso.

Ser consistente é importante, no entanto. Então eu disse: vamos jogar uma moeda e começar a escrever o código.

Já vi programadores resistirem a mudanças como essa antes. Deixe isso para trás! Eu mudei muitas vezes na minha carreira. Eu até uso estilos diferentes no meu C # do que no meu PowerShell.

Alguns anos atrás, eu estava trabalhando em uma equipe (~ 20 desenvolvedores) que decidiu pedir informações, tomar uma decisão e aplicá-la em toda a base de código. Teríamos 1 semana para decidir.

Muitos gemidos e revirar os olhos. Muitos "eu gosto do meu jeito, porque é melhor", mas sem substância.

Enquanto estudávamos os pontos mais delicados da pergunta, alguém perguntou como lidar com esse problema no estilo "prepare-se-na-mesma-linha":

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Observe que não é imediatamente óbvio onde a lista de parâmetros termina e o corpo começa. Comparado a:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Fizemos algumas leituras sobre como as pessoas ao redor do mundo haviam lidado com esse problema e descobrimos o padrão de adicionar uma linha em branco após a chave aberta:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Se você quiser fazer uma pausa visual, é melhor fazê-lo com uma chave. Então suas quebras visuais também se tornam consistentes.

Editar: Duas alternativas para a solução 'extra blank blank' ao usar K&R:

1/Recuar os argumentos da função de maneira diferente do corpo da função

2/Coloque o primeiro argumento na mesma linha que o nome da função e alinhe outros argumentos em novas linhas ao primeiro argumento

Exemplos:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/ Editar

Eu ainda argumento que a consistência é mais importante do que outras considerações, mas se não temos um precedente estabelecido, então a chave na próxima linha é o caminho a seguir.

206
Jay Bazuzi

As regras principais são:

  1. Siga o padrão de codificação existente do projeto.
  2. Se não houver um padrão de codificação e você estiver editando uma base de código existente pertencente a outra pessoa - seja consistente com o estilo do código existente, não importa o quanto você goste/não.
  3. Se você estiver trabalhando em um projeto de campo verde - discuta com outros membros da equipe e chegue a um consenso sobre um padrão de codificação formal ou informal.
  4. Se você estiver trabalhando em um projeto de campo verde como o único desenvolvedor - decida-se e depois seja cruelmente consistente.

Mesmo que você não tenha restrições externas, é melhor (IMO) procurar um padrão de codificação existente (amplamente utilizado) ou uma diretriz de estilo e tentar segui-lo. Se você adota seu próprio estilo, há uma boa chance de que você se arrependa em alguns anos.

Por fim, um estilo que é implementado/implementável usando verificadores de estilo e formatadores de código existentes é melhor do que aquele que precisa ser "imposto" manualmente.

103
Stephen C

O benefício do primeiro método é que ele é mais verticalmente compacto, para que você possa ajustar mais código na tela, e é por isso que eu prefiro. O único argumento que ouvi a favor do segundo método é que facilita o pareamento entre colchetes de abertura e fechamento, mas a maioria dos IDE tem um atalho de teclado para isso, e na verdade é uma declaração falsa - em vez de emparelhar um colchete de abertura a um fechamento colchete, você pode emparelhar um colchete de fechamento com a expressão "início do bloco" (se, além disso, por enquanto) no mesmo nível de indentação, para que seja igualmente fácil determinar onde está o início do bloco.

Não vejo razão para desperdiçar uma linha inteira apenas entre parênteses quando a construção anterior para/enquanto/se já indica visualmente o início de um bloco.

Dito isto, acredito que o colchete de fechamento deve estar em sua própria linha, porque precisamos de algo para indicar o fim de um bloco e sua estrutura de indentação de maneira visível.

72
EpsilonVector

Eu prefiro

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

sobre

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

porque a linha you.postAnswer(); é muito mais fácil de ler e encontrar à primeira vista. Na segunda maneira, ele se mistura com a linha acima dela (you.hasAnswer()) fazendo com que meus olhos tenham que se concentrar mais para lê-lo.

49
JD Isaacks

Eu prefiro o primeiro método. Aparelho não vale totalmente a linha separada.

O problema é que o aparelho não é importante. Eles são apenas lixo sintático, o que é absolutamente desnecessário para entender para que serve o código, qual é o seu objetivo e a maneira como é implementado. Eles são apenas um tributo às linguagens antigas do tipo C, onde o agrupamento visual de operadores era impossível devido ao pouco espaço disponível na tela.

Existem idiomas (Python, Haskell, Ruby) que são válidos sem chaves. Isso apenas confirma que os aparelhos são lixo e não deve merecer uma linha para eles sempre que possível:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}
39
P Shved

Use Python e evite o argumento completamente.

37
Mark Ransom

A posição dos aparelhos deve ser

metadados

configurável no IDE pelo programador. Dessa forma, essas chatas chaves em todo o código, independentemente do autor, têm a mesma aparência.

28
Jonathan

Eu prefiro o primeiro porque é mais difícil para mim ver o erro neste exemplo.

if (value > maximum);
{
    dosomething();
}

do que é neste exemplo

if (value > maximum); {
    dosomething();
}

O ; { me parece mais errado do que uma linha que termina com ; então é mais provável que eu note.

19
bmb

Depende.

Se eu estiver codificando em Javascript ou jQuery, utilizarei o primeiro formulário:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Mas se estou codificando em C #, utilizo a segunda forma, porque essa é a maneira canônica de fazê-lo em C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Observe que seu exemplo pode ser escrito

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

em c #.

19
Robert Harvey

Eu prefiro uma ligeira variante de 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Por quê?

  • Eu acho que sempre colocar chaves em sua própria linha diminui a legibilidade. Só posso ajustar uma certa quantidade de código fonte na minha tela. O estilo de colchete 2) torna os algoritmos de heave com muitos loops e condicionais aninhados dolorosamente longos.

  • No entanto, quero que else inicie em uma nova linha porque if e else pertençam juntos, visualmente. Se houver um colchete na frente do else, é muito mais difícil identificar o que pertence a quê.

  • 3) se desqualifica. Todos sabemos que coisas ruins podem acontecer se você deixar de fora os parênteses e esquecer.

15
Alexander Gessler

Eu li em algum lugar que os autores de um livro queriam que seu código fosse formatado assim:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Mas as restrições de espaço de seus editores significavam que eles precisavam usar isso:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Agora não sei se isso é verdade (como não consigo mais encontrá-lo), mas o último estilo é muito prevalente nos livros.

Em nível pessoal, prefiro os colchetes em uma linha separada como:

a) eles indicam um novo escopo
b) é mais fácil identificar quando há uma incompatibilidade (embora isso seja um problema menor em um IDE que destaca erros para você).

10
ChrisF

Ah, o m estilo de cinta verdadeira .

Tem tudo o que é necessário para um Caminho Sagrado - até um profeta (Richard "do meu jeito ou da estrada" Stallman).

O cara estava tão errado com tantas coisas, mas GNU é perfeito quando se trata de aparelhos).


[Atualização] Eu vi a luz, e agora adoro Allman

10
Mawg says reinstate Monica

Resposta simples: o que é mais fácil de depurar?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

Em qual caso você diagnosticou o problema primeiro?

Eu não ligo muito para preferências pessoais (existem muitos outros estilos, incluindo whitesmith e outros) e não ligo muito ... desde que isso não atrapalhe minha capacidade de ler o código e depurar isso.

Quanto ao argumento "desperdiçar espaço", não compro: tenho a tendência de adicionar linhas em branco entre grupos lógicos para tornar o programa mais claro ...

9
Matthieu M.

Segundo exemplo, eu sou muito grande em legibilidade. Não suporto olhar se bloqueia de outra maneira = (

9
Bryan Harrington

Não é que alguém notará, mas é por isso que os chavetas pertencem à condicional mesma linha (exceto condicionais muito longas, mas esse é um caso do Edge):

Em C, esta é uma construção válida:

 while (true); 
 {
 char c; 
 getchar (); // Aguarde a entrada 
} 

Rápido! O que faz este código? Se você respondeu "loop infinito pedindo entrada", está errado! Nem chega na entrada. É pego em while(true). Observe esse ponto e vírgula no final. Esse padrão é realmente mais comum do que parece; C requer que você declare suas variáveis ​​no início de um bloco, e é por isso que uma nova foi iniciada.

Uma linha de código é um pensamento. Chaves são uma parte do pensamento que contém o condicional ou loop. Portanto, eles pertencem à mesma linha.

8
Christian Mann

Eu gosto do primeiro método. Parece IMO mais limpo, e é mais compacto, o que eu gosto.

EDIT: Ah, um terço. Eu gosto desse melhor quando possível, pois é ainda menor/mais limpo.

5
Ullallulloo

Você pode escrever:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Para responder à pergunta; Eu costumava preferir chaves em sua própria linha, mas, para evitar pensar em bugs da inserção automática de ponto e vírgula nos navegadores, comecei a usar o estilo egípcio para javascript. E ao codificar Java no Eclipse, eu não tinha interesse em combater (ou configurar)) o estilo de chave padrão, então fui com o egípcio nesse caso também. Agora estou bem com ambos.

5
FeatureCreep

Quase todas as respostas aqui estão dizendo alguma variação em "Faça o que fizer, fique com uma ou duas".

Então pensei nisso por um momento e tive que admitir que simplesmente não considero isso tão importante. Alguém pode me dizer honestamente que é difícil seguir o seguinte?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Não tenho certeza de mais ninguém ... mas não tenho absolutamente nenhum problema de alternar mentalmente entre os estilos. Demorei alguns minutos para descobrir o que o código fazia, mas esse é o resultado de eu digitar aleatoriamente a sintaxe do tipo C. :)

Na minha opinião não tão humilde, as chaves de abertura são quase completamente irrelevantes para a legibilidade do código. Existem alguns casos de canto listados acima, nos quais um estilo ou outro faz diferença, mas, na maioria das vezes, o uso criterioso de linhas em branco limpa isso.

No FWIW, nossos estilos de codificação no trabalho usam uma forma um pouco mais estruturada 1 e uma forma modificada 3. (C++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Estou curioso para saber se aqueles que preferem o formulário 2 acham melhor essa versão do formulário 1, apenas porque a linha em branco oferece uma separação visual mais forte.

4
jkerian

Estou surpreso que isso ainda não tenha sido criado. Eu prefiro a segunda abordagem porque permite que você selecione o bloco mais facilmente.

Quando os colchetes começam e terminam na mesma coluna e em sua própria linha, é possível selecionar na margem ou com o cursor na coluna 0. Isso geralmente equivale a uma área mais generosa com a seleção do mouse ou menos pressionamentos de tecla com a seleção do teclado.

Originalmente, eu trabalhei com aparelhos na mesma linha do condicional, mas quando troquei, ele acelerou a taxa na qual trabalhava. Não é noite e dia, é claro, mas é algo que o atrasará um pouco, trabalhando com aparelhos ao lado de seus condicionais.

4
Tim O'Neil

Minha preferência pessoal é pelo primeiro método, provavelmente porque foi assim que aprendi PHP.

Para instruções de linha única if, usarei

if (you.hasAnswer()) you.postAnswer();

Se não for you.postAnswer();, mas algo muito mais longo, como you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); provavelmente voltarei ao primeiro tipo:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Nunca usarei uma quebra de linha e nunca usarei esse método se houver também uma instrução else.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

é uma possibilidade teórica, mas nunca uma que eu usaria. Isso teria que ser transformado em

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}
2
TRiG

Eu pessoalmente gosto do segundo caminho.

No entanto, na minha opinião, a maneira que vou demonstrar é melhor porque resulta em maior segurança no emprego! Um colega da minha universidade me pediu ajuda com o dever de casa e foi assim que o código dele se parecia. Todo o programa parecia um único bloco. O interessante é que 95% dos bugs do programa que ele criou vieram de chaves incompatíveis. Os outros 5% eram óbvios quando os aparelhos eram compatíveis.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);
2
AndrejaKo

Eles não deveriam; primeiro método para mim.

Quando olho para a segunda, por causa das linhas não utilizadas (aquelas que só têm chaves, exceto a última chave de fechamento), parece que isso quebra a continuidade do código. Não consigo lê-lo tão rápido porque preciso dedicar atenção especial às linhas vazias, que geralmente significam uma separação no objetivo do código ou algo assim, mas em nenhum caso "essa linha pertence a uma chave" (que apenas repete o significado recuo).

De qualquer forma, assim como quando você escreve um texto ... a adição de um recuo no início de um parágrafo é supérflua se houver uma linha em branco à sua frente (duplo sinal de alteração de parágrafo), não há necessidade de desperdiçar linhas para chaves quando estamos recuo corretamente.

Além disso, como já foi dito, ele permite ajustar mais código na tela, o que, de outra forma, é um pouco contraproducente.

2
Joanis

Depende da plataforma/idioma/convenções

Em Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

Em c #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

Em C:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Eu odeio quando Java usam seu estilo no código C # e vice-versa.

2
OscarRyz

Eu uso o primeiro método simplesmente porque é mais compacto e permite mais código na tela. Eu mesmo nunca tive problemas em emparelhar chaves (eu sempre as escrevo, juntamente com a instrução if antes de adicionar a condição, e a maioria dos ambientes permite que você pule para a chave correspondente).

Se você fez precisa emparelhar chaves visualmente, então eu preferiria o segundo método. No entanto, isso permite menos código ao mesmo tempo, o que exige que você role mais. E isso, para mim, pelo menos, tem um impacto maior na leitura do código do que ter chaves perfeitamente alinhadas. Eu odeio rolagem. Então, novamente, se você precisar rolar por uma única instrução if, é provável que ela seja muito grande e precise ser refatorada.

Mas; o mais importante de tudo é consistência. Use um ou outro - nunca os dois!

1
gablin

Tudo o que posso dizer é que, se você é fã do método nº 3, será perseguido por todos os formadores de código IDE na Terra).

1
Phil Cohen

Há uma quarta opção que mantém os aparelhos alinhados, mas não desperdiça espaço:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

O único problema é que a maioria dos formadores automáticos de IDE se engasga com isso.

0
AShelly

Quando aprendi a programação aos 12 anos, coloquei o aparelho na próxima linha, porque os tutoriais de codificação da Microsoft são assim. Eu também recuei com TABs de 4 espaços naquela época.

Depois de alguns anos, aprendi Java e JavaScript) e vi mais códigos de chaves na mesma linha, então mudei. Também comecei a recuar com espaços de 2 espaços.

0
Ming-Tang