Declarações de linha única e boas práticas

Recentemente, adquiri um hábito que muitos de vocês talvez desaprovam, mas que, no final, me ajuda a ficar de olho na estrutura global do código, e não na estrutura de um único método (às vezes) repetitivo: agrupar um número de instruções em uma única linha, assim:

textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!";

em oposição a

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

Costumo fazer isso em tarefas repetitivas para manter a "beleza" geral do código e para me ajudar a rastrear a estrutura do programa com facilidade, mas admito que pode não ser uma boa prática. Na verdade, eu uso muito, então gostaria de saber o que você pensa sobre isso. Além disso, você acha que alguém que precisaria manter meu código tem problemas com essa abordagem?

Eu realmente acho que a legibilidade sofreria muito tanto para você quanto para qualquer outra pessoa que estivesse lendo o código. Tudo faz sentido quando você o escreve pela primeira vez, porque está ativamente em sua mente. É diferente quando você está escaneando código para ver quais variáveis ​​e funções estão ... você está destruindo sua própria capacidade de escanear seu próprio código. Isso é uma enorme falta de nenhum, e além ruim se ninguém nunca tem que ler o seu código.

Além disso, pense em como você lê o código. É sempre de cima para baixo, rolando para baixo. Seu método não combina com isso e até introduz um dos problemas mais feios possíveis na leitura de código; rolando horizontalmente . Nunca subestime o quão difícil isso pode dificultar a leitura do código. Você nunca rola na horizontal, nunca faz as pessoas rolarem horizontalmente, em quase qualquer contexto é extremamente antinatural.

Além disso, se o seu problema for entrada repetitiva de código ... não se esqueça de Ctrl-C. No seu código de exemplo, pode ser mais eficiente digitar tudo manualmente, mas se você precisar copiar várias linhas várias vezes, parece que seria tão eficiente copiar a linha um mais uma nova linha, cole-a x vezes e faça as alterações, menos propensas a digitar também.

Ah, e erros de digitação! Prejudicar a legibilidade do seu código assim pode tornar um pesadelo descobrir qual das 50 declarações de variáveis ​​que você definiu incorretamente. A maioria dos compiladores fornece erros nos números de linha e coluna agora, mas encontrar um erro em uma linha é MUITO mais fácil do que encontrar uma coluna.

Uma declaração por linha também facilita a visualização do que mudou em uma comparação lado a lado.

Embora o exemplo não mostre isso, há outro problema ao agrupar várias instruções em uma linha. E se uma das cinco instruções que você possui em uma única linha lança uma exceção?

Seu rastreamento de pilha dirá "EBlah na linha N" ... e agora você não tem idéia de qual dessas cinco instruções lançou a exceção.

(O mesmo acontece com uma declaração excessivamente longa de qualquer tipo.)

Uma declaração por linha é um estilo de codificação amplamente usado. Como resultado, a maioria dos desenvolvedores que olharem para o seu código no futuro provavelmente estremecerá quando virem várias instruções por linha. Quando você está acostumado a ver algo de uma maneira, pode ser desorientador ver de outra maneira.

Por esse motivo, desaconselho, exceto em raras circunstâncias.

Fiz isso pela última vez há 25 anos, usando linguagens interpretadas em pequenos micros rodando com baixas velocidades de clock, onde cada espaço ou retorno de carro eliminado dava um aumento de desempenho.

Eu estremeço agora ao pensar nisso (embora tenha sido feito por um bom motivo).

Infelizmente, esse código é difícil de ler e, portanto, difícil de manter.

Sintaticamente, não há realmente nada de errado com isso. Realmente depende do estilo de codificação da sua equipe.

Como a maior parte do código que eu vi (incluindo o código que está dentro dos cabeçalhos c ++ padrão) é feita dessa maneira, eu usaria seu primeiro método.

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

Esse é um estilo de codificação realmente incomum.

Eu recomendo que você use linhas vazias para delimitar partes lógicas do código.

Ir muito longe para a direita pode criar tantos problemas quanto várias linhas.

Eu tive que lidar com algumas instruções sql com dezenas de campos. Normalmente, eu colocaria uma por linha, mas em algumas ocasiões, consolidei 3 ou 4 em uma linha. Parece uma boa ideia durante o desenvolvimento, quando você tem que rolar para cima e para baixo várias vezes.

Lamento voltar a este código. Ter linhas extras não parece criar muito problema, então eu costumo limpá-las.

Além disso, você acha que alguém que precisaria manter meu código tem problemas com essa abordagem?

Depois de colocar as mãos na cabeça por um minuto, ele usará suas funcionalidades IDE Regex favoritas para separar automaticamente todo esse código ilegível em uma instrução por linha.

Basta uma rápida olhada no exemplo que você mostrou é suficiente para entender o quanto mais legível é a segunda abordagem.

É muito mais fácil acompanhar o fluxo vertical da página, sem ter os olhos para mover horizontalmente para sempre.

Veja o seu exemplo: você sabe imediatamente que o código tem tudo a ver com a Textpropriedade de textBoxobjetos diferentes e eles contêm string como valores. Bem direto.

Eu pessoalmente não usaria esse estilo. Resumir

Prós

• menos linhas de código para percorrer
• pode ser usado para agrupar semanticamente o código para expressar: "um monte de coisas de atribuição". Mas você sempre pode refatorar esse bloco em uma função se isso o incomodar demais.

Contras

• difícil de ler, geralmente é mais fácil ler o código horizontalmente (deslizar, sem movimento dos olhos, ...)
• diff facilmente se torna um pesadelo, incluindo a fusão
• mais difícil de alterar (copiar e colar, comentar, ...)
• a depuração pode ser um problema em muitos IDEs, pois eles trabalham em linhas, em vez de expressões individuais.