Já houve algumas observações sobre o espaço em branco na discussão sobre posicionamentos de chaves.

Eu próprio tendem a borrifar meu código com linhas em branco, na tentativa de segregar coisas que se juntam em grupos "lógicos" e, espero, facilitar a próxima pessoa a ler o código que acabei de produzir.

Na verdade, eu diria que estruturo meu código como escrevo: faço parágrafos, não mais do que algumas linhas (definitivamente menores que 10), e tento tornar cada parágrafo independente.

Por exemplo:

• em uma classe, agruparei métodos que andam juntos, enquanto os separo por uma linha em branco do próximo grupo.
• se eu precisar escrever um comentário, normalmente colocarei uma linha em branco antes do comentário
• em um método, faço um parágrafo por etapa do processo

No geral, raramente tenho mais de 4/5 linhas agrupadas, o que significa um código muito esparso.

Não considero todo esse espaço em branco um desperdício, porque na verdade eu o uso para estruturar o código (como na verdade eu uso o recuo) e, portanto, acho que vale a pena o espaço de tela necessário.

Por exemplo:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Considero que as duas afirmações têm objetivos distintos e claros e, portanto, merecem ser separados para torná-lo óbvio.

Então, como você realmente usa (ou não) linhas em branco no código?

Sempre

Espaço em branco é crucial para limpar código legível. Uma linha em branco (ou duas) ajuda a separar visualmente os blocos lógicos de código.

Por exemplo, no capítulo Code Complete, Second Edition , de Steve McConnell, sobre Layout e estilo:

Os indivíduos obtiveram uma pontuação de 20 a 30% mais alta em um teste de compreensão quando os programas tinham um esquema de indentação de dois a quatro espaços do que quando os programas não tinham indentação.O mesmo estudo constatou que era importante não enfatizar nem enfatizar demais a estrutura lógica de um programa. Os menores escores de compreensão foram alcançados em programas que não eram recuados. A segunda mais baixa foi alcançada em programas que usavam recuo de seis espaços. O estudo concluiu que o recuo de dois a quatro espaços era ideal. Curiosamente, muitos sujeitos do experimento achavam que o recuo de seis espaços era mais fácil de usar do que os recuos menores, mesmo que suas pontuações fossem mais baixas. Provavelmente porque seis recuos espaciais parecem agradáveis. Mas, independentemente da aparência, o recuo de seis espaços acaba sendo menos legível. Este é um exemplo de colisão entre apelo estético e legibilidade.

Sim para maior clareza.

Assim como eu fiz nesta resposta.

Sim, mas certifico-me de documentá-lo colocando

(This line intentionally left blank.)

na linha

Sim, mas não abusei.

Eu vi código em que todas as linhas de código dentro de um método são separadas por uma linha em branco e duas linhas em branco são usadas onde ocorre uma separação lógica. Isso apenas torna ainda menos legível na minha opinião. Eu também vi espaços em branco usados ​​para fazer alinhamentos malucos, como este:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

O mesmo uso indevido do espaço em branco horizontal pode ser aplicado ao espaço em branco vertical. Como qualquer ferramenta, use-a com sabedoria.

Sou muito criticado por escrever meu código dessa maneira. Não entendo por que alguém não faria dessa maneira.

Legibilidade é tão importante quando você volta a um projeto após um longo período de tempo e ouvi um ditado "Sempre escreva código se o próximo cara que estiver lendo isso for um psicopata que conhece sua localização".

Nem sempre escrevo software, mas quando escrevo, uso linhas em branco para maior clareza.

Eu sou a favor de tornar o código o mais claro possível, e o espaço em branco geralmente é uma ferramenta útil nesse esforço. Mas não vamos esquecer a refatoração:

• em uma classe, agruparei métodos que andam juntos, enquanto os separo por uma linha em branco do próximo grupo.

Como você tem vários membros relacionados, eles são candidatos a uma nova classe.

• se eu precisar escrever um comentário, normalmente colocarei uma linha em branco antes do comentário

Sempre que o código não é claro o suficiente para querer um comentário, pergunto se posso refatorar para torná-lo claro o suficiente para não precisar do comentário.

• em um método, faço um parágrafo por etapa do processo

Por que não criar um método para cada "parágrafo"?

Se você acabar com vários métodos em sua classe, veja minha nota acima sobre como extrair uma nova classe.

Sim. Isso facilita a verificação visual de um arquivo. Entre outras coisas, fica mais claro com qual linha um comentário se encaixa.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

Uso linhas em branco com moderação e consistência, e consistentemente é mais importante do que com moderação. Contudo:

• Se cada linha de código for separada da seguinte por uma linha em branco, há muitas linhas em branco.
• Se não há rima nem razão prontamente discerníveis para onde as linhas em branco são colocadas, elas são uma distração e geralmente há muitas delas.
• Se uma função é tão grande que precisa de muitas linhas em branco, é muito grande.
• Se um bloco de código precisar de mais de uma linha em branco antes ou depois dele, há algo seriamente errado.
• Se você tiver mais de duas linhas em branco entre as funções, provavelmente terá muitas linhas em branco.

A maior parte disso não é terrivelmente controversa; o que se segue pode ser. Observo que a notação K&R com chaves abertas no final da linha é deprimente frequentemente seguida por uma linha em branco. Pessoalmente, não gosto dos aparelhos no final da linha e misturo isso com uma linha em branco após o aparelho fazer um absurdo da notação (IMNSHO). Coloque a chave aberta na próxima linha, por si só, e você terá uma linha principalmente em branco (e, IMNSHO, código mais legível). Se você precisar usar a cinta K&R no final da linha, não desperdice o espaço vertical economizando com linhas em branco estranhas.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Escreva o que é mais legível e menos surpreendente.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Esta função não precisa de 12 linhas de comentários do documento.

De fato, não precisa de comentários.

Ou linhas em branco.

Eles prejudicariam sua essência.

Dentro da função? Raramente

Se eu tiver um bloco claro e diferente, ele será refatorado para uma nova função. Se poucos casos não valem a pena.

Para mim, as linhas em branco na função são uma das "melhores práticas" erradas.

Frequentemente

Use-o para blocos lógicos de código que são processados ​​de maneira semelhante. Depois de adicionar um comentário para mostrar que você está executando uma etapa diferente - é hora de Extrair o Método.

Bom espaço em branco

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Espaço em branco inválido

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Não apenas uso espaços em branco, como chaves para maior clareza.

Aparelho que uso para dizer que essas podem ser potencialmente funções.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

Ao mesmo tempo, eu espalhava linhas em branco liberalmente em todo o meu código. Atualmente, eu tendem a ser mais poupadores. Eu acho que isso faz parte do que Steve Yegge estava falando aqui :

Espero que a cena que eu pintei até agora o ajude a entender por que às vezes você olha o código e o odeia imediatamente. Se você é um n00b, verá um código experiente e dirá que é uma porcaria impenetrável e indisciplinada, escrita por alguém que nunca aprendeu o essencial da engenharia de software moderna. Se você é um veterano, vai olhar para o código n00b e dizer que é um comentário ornamental excessivamente comentado que um estagiário poderia ter escrito em uma única noite de bebedeira.

O ponto de discórdia é a tolerância à compressão. À medida que você escreve código em sua carreira, especialmente se ele abrange idiomas e domínios de problemas muito diferentes, sua tolerância à compactação de código aumenta. Não é diferente da progressão da leitura de livros infantis com texto gigante para romances cada vez mais complexos com texto menor e palavras maiores.

...

Um programador com alta tolerância à compactação é realmente prejudicado por uma tela cheia de histórias. Por quê? Porque, para entender uma base de código, você deve poder incluir o máximo possível dela em sua cabeça. Se for um algoritmo complicado, um programador veterano deseja ver tudo na tela, o que significa reduzir o número de linhas em branco e comentários em linha - especialmente comentários que simplesmente reiteram o que o código está fazendo. É exatamente o oposto do que um programador n00b deseja. O n00bs quer se concentrar em uma declaração ou expressão de cada vez, afastando todo o código ao seu redor, para que possam se concentrar, chorando alto.

Eu concordo fundamentalmente com ele. É muito melhor compactar o código para que você possa obter o máximo possível em uma tela do que espaçá-lo demais. Isso não quer dizer que você nunca deve usar linhas em branco. Acho que, a menos que o agrupamento que você está tentando criar não aumente imensamente a legibilidade, isso causa mais mal do que bem.

Um professor emérito deu dois grandes conselhos

1. O espaço em branco é gratuito
2. Não use os grampos que aparecem na frente do papel, ou eu falharei com você.

Minhas regras de ouro são estas:

1. Se tiver problemas para ler o código que escrevi ontem, provavelmente preciso extrair um método ou três.

2. Se minha definição de classe for muito longa para ser lida com facilidade, provavelmente preciso extrair um módulo / interface / objeto.

3. Definições de método: adicione uma linha

4. Definições de módulo / classe: adicione duas linhas

Eu gosto de pensar em espaços em branco da mesma maneira que em parágrafos. Você agrupa linhas que contribuem para uma ideia.

Se você está iniciando uma nova idéia ou uma nova faceta da mesma idéia, inicia um novo parágrafo - assim.

No código imperativo, agrupo tarefas que realizam uma tarefa coesa; no código declarativo, agrupo o código que descreve uma afirmação coesa de uma ideia.

Você claramente não tem problemas em fazer isso em inglês (algumas pessoas são horríveis com parágrafos); portanto, com um pouco de prática, aplicar a mesma habilidade ao código não deve ser muito difícil.

Linhas em branco são uma obrigação na minha opinião. Eu os uso para separar diferentes blocos lógicos de código. Torna o código legível. Código legível é um bom código;)

Meu código ideal seria cada bloco lógico sendo separado por uma linha em branco e um comentário no topo de cada bloco que tenha uma lógica principal.

Obviamente, se as pessoas fazem isso adicionando várias linhas em branco em todos os lugares, acho isso muito irritante :(

Eu só uso espaços em branco em uma função / método para separar declarações e código.

Se você sentir a necessidade de ter algumas linhas para separar sub-blocos de código implementando alguma lógica, eles devem estar em outra função / método privado. Cabe ao seu compilador não sobrecarregar muito.

normalmente, no código peusdo:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Se vejo espaços em branco inúteis, geralmente me encolho.

O espaço em branco é extremamente valioso.

Aqui está o negócio ... os nerds que escrevem código complicado como E = MC ² são ótimos em mostrar suas habilidades de programação.

Agora vamos avançar seis meses, e são 2:00 da manhã e o sistema que não foi examinado em seis meses quebrou na linha E = MC ² . Isso é quase impossível de depurar ... todo mundo está enlouquecendo.

Suponha que o código se pareça mais com isso ...

See Dick
See Jane
See Dick and Jan

Se for 02:00 e o código estiver quebrado. Uma rápida olhada mostrará que a linha três deveria ter sido

See Dick and Jane

Problema resolvido.

Bottom Line ... use espaço em branco.

Como muitos outros declararam, as linhas em branco facilitam a leitura do código. No entanto, existem alguns idiomas que impõem esse padrão. Um que eu consigo pensar em cima da minha cabeça (não muito sobre linhas em branco, mas recuo adequado) é Python.

Eu concordo, eu uso espaços em branco da mesma maneira. No entanto, se eu me encontrar usando espaço em branco para dividir um método em muitas partes, é um sinal de que talvez seja necessário refatorar esse código em vários métodos. Muitas seções lógicas em um método podem sinalizar que o método será mais difícil de testar.

Eu os uso para separar o código em unidades lógicas. Eu já vi muito poucos exemplos de código que não usavam linhas em branco, é claro que a ofuscação é excetuada.

A resposta do psicopata é a melhor, mas eu a substituiria por assumir que a próxima pessoa é uma idiota, e que ela assumirá que você é e você desejará provar que está errada.

Tão importante quanto a legibilidade é o uso de comentários. Abro cada função ou sub-rotina com um bloco de comentários, explicando em texto não criptografado, o que é, o que faz, quais são os argumentos e quais são os resultados esperados (incluindo uma lista de condições de erro). Então não há dúvida sobre o que se destina e / ou se destina a fazer. O que ele alcança pode variar, mas isso é mais adiante.

Eu acho que muitos codificadores assumem que serão eles mesmos que farão "reparos" no código ou simplesmente não se importam.

Linhas em branco são importantes. No entanto, desperdiçar uma linha em branco inteira na chave de abertura reduz a quantidade de código que você pode ver em uma tela. Deveria estar:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Não comece a colocar a chave '{' na mesma linha que a 'for' ... isso é meshuggah).

Sim. Para legibilidade. Às vezes até coloco linhas em branco no código que não escrevi. Acho mais fácil entender o código quando eles têm um agrupamento lógico por meio de linhas em branco - como se você pudesse "ler rapidamente" através dele.

Devemos usar linhas em branco entre os bloqueios de código, como fazemos quando escrevemos uma carta.

Por exemplo, entre funções, ou dentro de uma função quando finalizamos um loop ...

As pessoas agradecerão um código limpo se tiverem que fazer manutenção nele;)

Usamos o espaço em branco recomendado pelo Microsoft StyleCop. Além da legibilidade e consistência, descobri que (junto com turmas pequenas) o código adequadamente organizado facilita muito o gerenciamento de mesclagens quando várias pessoas de uma equipe trabalham nas mesmas áreas.

Não tenho certeza se é apenas minha imaginação, mas as ferramentas diferentes parecem fazer um trabalho melhor em reconhecer onde um código equivalente inicia e termina quando se mescla quando é organizado de maneira organizada. Código bem organizado é uma alegria para mesclar. Ok, isso era mentira - mas pelo menos a dor é mantida em níveis administráveis.

Nunca uma linha em branco, não está no arquivo inteiro. Isso não quer dizer que não haja quebras no código:

 code;
 //
 morecode;

Linhas em branco são para abrir seções do código para trabalhar, você tem algumas teclas de atalho no seu editor para levá-lo para a linha em branco anterior / seguinte.