Pergunta

Minha intenção nesta questão não é ser pedante, mas explorar um eixo esquecido de um tópico importante (o uso do espaço em branco). Muito debate e cuidados foram colocados no uso do espaço em branco horizontal, recuando após um condicional, um espaço entre um IF e parênteses, etc. De fato, a questão é considerada tão importante e controversa que, não apenas algumas empresas têm regras e padrões para isso, mas algumas empresas ainda têm regras que proíbem sua discussão.

Por que, considerando o estado do espaço em branco horizontal, que a discussão do espaço em branco vertical é uma questão tão morta? Porque é o x mais importante que o y? Alguns dias atrás, notei que, ao ler o código, sem pensar, geralmente ajusto os agrupamentos verticais de declarações. Depois de ler o código de outras pessoas agora, com o olho no espaço em branco vertical, notei vários padrões, por isso peço StackOverflow:

  • Que regras duras e suaves você se aplica ao espaço em branco vertical?
  • Existem usos de espaço em branco vertical que geralmente são considerados muito ruins ou muito boas práticas?
  • Você encontrou o código de leitura com o espaço em branco vertical "correto" ajudou a entendê -lo?
  • Alguém que não seja tipógrafos e eu me importo?
Foi útil?

Solução

Eu olho para o espaço vertical no código da maneira como olho para os parágrafos em prosa escrita. Assim como um parágrafo destina -se a agrupar frases que têm um ponto ou idéia comum, as linhas relacionadas devem ser agrupadas.

O objetivo geral é melhorar a legibilidade do código. Assim como um artigo sem parágrafos seria difícil de ler, então é o código IS sem nenhum espaço vertical. E assim como na prosa, há um equilíbrio entre compor parágrafos que são muito curtos ou muito longos. Mas, no final, tudo se resume principalmente ao estilo e preferência pessoal.

Outras dicas

Eu acho que uma das coisas mais importantes é agrupar um passo lógico juntos, como:

foo.setBar(1);
foo.setBar2(2);
foo.writeToDatabase();

bar.setBar(1)
bar.setBaz(2);
bar.writeToDatabase();

Dessa forma, o código é mais fácil de ler e é mais descritivo para mim de qualquer maneira.

Se um grupo de declarações estiver logicamente relacionado, dou uma linha em branco antes e depois. Essa separação ajuda se eu precisar refatorá -la em uma função posteriormente.

Quanto às linhas em branco duplo: se algo é tão distinto, você realmente deve considerá -lo uma função.

Se um comentário se aplicar a várias linhas de código, eu coloco o espaço em branco após a última dessas linhas, a não ser que Há outra sintaxe para quebrar as coisas (como o final de um bloco).

Em qualquer lugar que eu esteja fazendo "algo", que leva várias linhas de código, imediatamente seguido por "outra coisa", então abstrairei em funções separadas ou colocarei comentários [*]. Portanto, as linhas de código geralmente acabam agrupadas em blocos curtos, exceto quando o controle de fluxo o torna (na minha opinião) auto-explicativo.

Eu me importo um pouco com o espaço em branco, mas na verdade são os comentários que me preocupo mais. Se algumas linhas de código juntas fazem alguma coisa específica e não foi retirada como uma função, gostaria de ver uma descrição em inglês do que é essa. Dessa forma, posso ver que as "etapas" da função realmente somam o resultado certo e, em seguida, veja que cada etapa faz o que afirma fazer.

Nas aulas, às vezes coloco espaço em branco entre métodos/funções de membro e às vezes não. Em C ++, coloquei espaço em branco antes dos especificadores de acesso.

Coloquei espaço em branco entre as aulas (às vezes não para aulas internas anônimas em Java) e entre funções fora das classes.

Fora isso, meu código é bastante denso verticalmente. Quase nunca uso várias linhas em branco, mesmo ao separar seções de um arquivo de cabeçalho e similares. Eu preferiria a queima-roupa em branco-base-commentline, em vez de a BlankLine-Blankline, mesmo que a linha de comentários acabe sendo algo completamente banal, como "funções auxiliares". Não gosto de estilos que tenham um espaço de branco enorme entre as funções - se elas são tão separadas que você não quer vê /Javadoc Comentários.

*] Na versão em que faço o check -in. Normalmente escrevo código mais ou menos sem comentários e, em seguida, compro -o, execute testes rápidos, comento, execute testes adequados, comprometa -o. Isso geralmente muda um pouco, e às vezes muito. Por exemplo, se estou codificando um algoritmo que é definido com precisão com antecedência ou para uma especificação em que a implementação é "óbvia", posso escrever os comentários primeiro e depois o código.

Sabe -se há décadas que a capacidade de um programador de entender geralmente é limitada por quanto dele ele pode ver ao mesmo tempo. (Veja, por exemplo, Weinberg, "Psicologia da programação de computadores", um antigo, mas bucina.) Nos velhos tempos de listagens de papel, os programadores pegavam grandes mesas e espalhavam várias páginas de listagem. Atualmente, o Screen Real Estate é um pouco melhor que os dias de 24x80, mas eu ainda tendem a minimizar o uso do espaço em branco vertical, já que muitas linhas em branco ocupam espaço na tela que podem me mostrar o código real.

Eu certamente me importo e tendem a agrupar o código corretamente (pelo menos para meus olhos) com linhas em branco, quando apropriado. Muitas vezes, isso significa muitas linhas em branco, mas em geral considero o código mais legível do que tudo abrigada. Assim como os espaços ao redor dos operadores são uma coisa muito boa, as linhas em branco em torno de declarações de grupo logicamente.

Mais de uma única linha em branco parece um pouco fora do lugar.

Acho difícil ler se o código é espaçado verticalmente. Eu até chego ao ponto de remover os aparelhos não necessários, ou se forem blocos curtos, como IFS ou FORS, coloque -o na mesma linha.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top