As chaves devem aparecer na sua própria linha? [fechadas]

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 caractere de colchete único impresso como a única coisa em uma linha é irritante. (ambiente, desperdício de papel)

Mas quando se codifica aplicações grandes, permitir algumas linhas com apenas chaves é acessível, considerando o sentimento de 'agrupamento' que dá.

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 relacionadas de código . Em diferentes cenários (como acima) eu diria que não há problema em usar estilos diferentes, é mais fácil "mudar de contexto" em um nível alto.

Você nunca deve fazer o 3º método.

Diminuir os aparelhos pode economizar algumas teclas na primeira vez, mas o próximo codificador que aparecer acrescenta algo à sua cláusula else sem notar que o bloco está faltando, o aparelho vai causar muita dor.

Escreva seu código para outras pessoas.

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

Eu já vi programadores resistirem a mudanças assim 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.

Há alguns anos, eu estava trabalhando em uma equipe (~ 20 desenvolvedores) que decidiu solicitar informações e, em seguida, tomar uma decisão e, em seguida, aplicá-la em toda a base de código. Nós teríamos uma semana para decidir.

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

Como estávamos estudando os pontos mais delicados da pergunta, alguém perguntou como lidar com esse problema no estilo de usar a mesma linha:

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

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

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

Fizemos algumas leituras sobre como as pessoas em todo o mundo lidaram 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ê vai fazer uma pausa visual, você pode fazer isso com uma chave. Então, suas quebras visuais se tornam consistentes também.

Editar : duas alternativas para a solução "linha extra em branco" ao usar o K & R:

1 / Indente 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 mais argumentos em novas linhas para o 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ós não tivermos um precedente estabelecido , então o brace-on-next-line é o caminho a ser seguido.

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 goste.
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 - faça sua própria opinião e, em seguida, seja impiedosamente consistente.

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

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

O benefício do primeiro método é que ele é mais verticalmente compacto, para que você possa ajustar mais código em sua tela, e é por isso que eu prefiro. O único argumento que ouvi em favor do segundo método é que é mais fácil parear os 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 colchete você pode emparelhar um colchete de fechamento com a expressão "início do bloco" (if, else, for, while) no mesmo nível de indentação, então é tão fácil determinar onde está o início do bloco.

Não vejo razão para desperdiçar uma linha inteira apenas para um colchete quando a construção de / while / if anterior já indica visualmente o início de um bloco.

Dito isso, acredito que o colchete de fechamento deveria 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();
}

mais de

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

porque a linha you.postAnswer(); é muito mais fácil de ler e encontrar à primeira vista. No segundo modo, ele fica misturado com a linha acima dele ( you.hasAnswer() ) fazendo com que meus olhos fiquem mais focados para lê-lo.

Eu prefiro o primeiro método. Chaves não valem totalmente a linha separada.

O problema é que os aparelhos não são importantes. Eles são apenas lixo sintático , o que é absolutamente desnecessário para entender o que é o código, o propósito e a maneira como ele é implementado. Eles são apenas uma homenagem às antigas linguagens tipo C, em que o agrupamento visual de operadores era impossível devido ao baixo espaço disponível na tela.

Existem linguagens (Python, Haskell, Ruby) que estão bem sem chaves. Isso só confirma que as chaves são lixo e não devem merecer uma linha para elas sempre que possível:

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

Use o Python e evite o argumento completamente.

A posição das chaves deve ser

metadados

configurável no IDE pelo programador. Dessa forma, essas chaves traquinas em todo o código, independentemente do autor, parecem iguais.

Depende.

Se eu estou codificando em Javascript ou jQuery, eu uso o primeiro formulário:

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

Mas se eu estou codificando em C #, eu uso o segundo formulário, 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 ; { parece mais errado para mim do que uma linha que termina com ; , por isso é mais provável que eu note isso.

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 colocando chaves em sua própria linha diminui a legibilidade. Eu só posso encaixar uma certa quantidade de código-fonte na minha tela. O estilo de suporte 2) torna os algoritmos heave com muitos loops aninhados e condicionais dolorosamente longos.

• No entanto, quero que else comece em uma nova linha porque if e else estão 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 lado os colchetes e esquecer isso.

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

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

Mas as restrições de espaço de sua editora significaram que eles precisavam usar isso:

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

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

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

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

Segundo exemplo, sou muito bom em legibilidade. Eu 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 que casos você diagnosticou o problema primeiro?

Eu não me importo muito com as preferências pessoais (há muitos outros estilos, incluindo whitesmith e al.) e não me importo muito ... contanto que isso não prejudique a minha capacidade de ler o código e depurar .

Quanto ao argumento "desperdício de espaço", não o compro: tendem a adicionar linhas em branco entre grupos lógicos de qualquer forma para tornar o programa mais claro ...

Não que alguém perceba, mas é por isso que as chaves pertencem à mesma linha como condicional (exceto por condicionais muito longos, mas isso é um caso extremo):

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

while(true);
{
    char c;
    getchar(); //Wait for input
}

Rápido! O que faz este código? Se você respondeu "loop infinito pedindo entrada", você está errado! Não chega nem à entrada. Ele é pego em while(true) . Observe que ponto e vírgula no final. Este padrão é na verdade mais comum que parece que deveria ser; C exige 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 terceiro. Eu gosto disso sempre que possível, pois é ainda menor / mais puro.

Você pode escrever:

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

Para responder a pergunta; Eu costumava preferir chaves em sua própria linha, mas, para evitar ter que pensar sobre erros de inserção automática de ponto-e-vírgula em navegadores eu comecei a usar o estilo egípcio para javascript. E ao codificar java no eclipse eu não tinha interesse em lutar (ou configurar) o estilo de chave padrão, então eu também fui com o Egyptian nesse caso. Agora estou bem com os dois.

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

Então eu pensei sobre isso por um momento, e tive que admitir que eu não vejo isso como importante. Alguém pode honestamente me dizer que o seguinte é difícil de seguir?

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

Eu não tenho certeza sobre mais ninguém ... mas eu tenho absolutamente zero problemas mentalmente alternando entre os estilos. Demorei alguns instantes para descobrir o que o código fazia, mas esse é o resultado de eu apenas digitar aleatoriamente uma sintaxe similar a 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, onde um estilo ou outro faz a diferença, mas na maior parte, o uso criterioso de linhas em branco limpa isso.

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, porque a linha em branco proporciona uma separação visual mais strong.

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

Quando as chaves começam e terminam na mesma coluna e em sua própria linha, você pode selecionar a partir da margem ou com o cursor na coluna 0. Isso geralmente equivale a uma área mais generosa com seleção de mouse ou menos pressionamentos de tecla com a seleção do teclado .

Eu originalmente trabalhei com chaves na mesma linha que a condicional, mas quando mudei achei que acelerava a taxa em que eu trabalhava. Não é noite e dia, é claro, mas é algo que vai te atrapalhar um pouco ao trabalhar com chaves ao lado de seus condicionais.

Eu pessoalmente gosto da segunda maneira.

No entanto, a maneira como vou demonstrar é, na minha opinião, 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 seu código se parecia. Todo o programa parecia um único bloco. O interessante é que 95% dos erros no programa que ele fez vieram de chaves incompatíveis. Os outros 5% eram óbvios, uma vez que os aparelhos foram combinados.

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]='
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]='%pre%';
                puts(input);
';
                puts(input);

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

Para instruções if 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 instrução else .

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

é uma possibilidade teórica, mas não uma que eu usei. Isso teria que ser transformado em

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

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

Quando eu olho para o segundo, por causa das linhas não utilizadas (aquelas que só possuem chaves, além da última chave de fechamento), parece que quebra a continuidade do código. Eu não consigo ler tão rápido porque eu preciso dar atenção especial às linhas vazias que normalmente significam uma separação no código ou algo assim, mas em nenhum caso "esta linha pertence a uma chave" (que apenas repete o significado de indentação).

De qualquer forma, assim como quando você escreve texto ... adicionar um recuo no início de um parágrafo é supérfluo se houver uma linha em branco antes dele (sinal duplo de alteração de parágrafo), não há necessidade de perder linhas para chaves quando estamos indentando corretamente.

Além disso, como já foi dito, permite caber mais código na tela, o que é 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 caras de Java usam seu estilo em código C # e vice-versa.

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

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

Se você tiver necessidade de emparelhar as chaves visualmente, então eu preferiria o segundo método. No entanto, isso permite menos código de uma só vez, o que requer que você role mais. E isso, pelo menos para mim, tem um impacto maior na leitura de código do que ter chaves bem alinhadas. Eu odeio rolagem. Então, novamente, se você precisar rolar por uma única instrução if , é muito provável que ela seja grande demais e precise de refatoração.

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

Quando comecei a aprender programação aos 12 anos, coloquei as chaves na próxima linha porque os tutoriais de codificação da Microsoft são assim. Eu também indentifiquei com TABS de 4 espaços esse tempo.

Depois de alguns anos, aprendi Java e JavaScript, e vi mais chaves no mesmo código, então mudei. Eu também comecei a recuar com espaços de 2 espaços.

Existe uma quarta opção que mantém as chaves alinhadas, mas não desperdiça espaço:

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

O único problema é que a maioria dos autoformatadores do IDE se engasga com isso.

Tudo depende de você, desde que você não esteja trabalhando em um projeto em que algumas restrições de codificação ou alguns padrões tenham sido 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 1º método.

Eu também não consegui o que você quer mostrar pelo 3º método?

Isso não é um 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 declaraçõ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();