Aparelhos devem aparecer em sua própria linha? [fechadas]

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.

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 cérebro processar vários estilos em partes de 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.

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.

Por um longo tempo, argumentei que eles tinham igual valor, ou tão próximos de igual que o possível ganho ao fazer a escolha certa estava muito, muito abaixo do custo de discutir 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 em todo o 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.

Edit : 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 , o melhor caminho é seguir em frente.

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 seja implacavelmente 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 seguir. Se você seguir 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.

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 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.

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, ela se mistura com a linha acima dela ( you.hasAnswer()), fazendo com que meus olhos tenham que se concentrar mais para lê-la.

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();
}

Use Python e evite o argumento completamente.

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.

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 #.

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 que ; {me parece mais errado do que uma linha que termina com, ;então é mais provável que eu note.

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 aparelho na 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 elsecomeçar em uma nova linha porque ife elsepertenço juntos, visualmente. Se houver um suporte na frente do else, é muito mais difícil identificar o que pertence ao quê.

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

Eu li em algum lugar que os autores de algum 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 destaque erros para você).

Ah, o único estilo de cinta verdadeira .

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

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

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

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

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 depurá- lo.

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 ...

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

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

while (verdadeiro);
{
    char c;
    getchar (); // Aguardar 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.

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.

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, por isso também fui com o egípcio. Agora estou bem com os dois.

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 a 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.

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 chavetas 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, descobri que ele acelerava 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.

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 a lição 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 no 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);

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

Para ifinstruções de linha única , 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 elsedeclaração.

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();
}

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.

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 os caras do Java usam seu estilo no código C # e vice-versa.

Tudo o que posso dizer é que, se você é fã do método nº 3, será perseguido por qualquer formatador de código IDE do mundo.

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

Se você fez precisa emparelhar-se 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. Por outro lado, se você precisar rolar uma única ifdeclaração, é 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!

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. Eu também comecei a recuar com 2 espaços.

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.

Tudo depende de você, desde que não esteja trabalhando em um projeto em que algumas restrições de codificação ou alguns padrões foram definidos pelo gerente de projeto que todos os programadores que estão trabalhando nesse projeto devem seguir durante a codificação.

Eu, pessoalmente, preferiria o primeiro método.

Também não entendi o que você quer mostrar pelo terceiro método?

Não é esse o caminho errado? Por exemplo, considere uma situação como ..

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

Agora, e se alguém quiser adicionar mais algumas instruções no bloco if ?

Nesse caso, se você usar o terceiro método, o compilador lançará o erro de sintaxe.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();