Usando dois pontos para colocar duas instruções na mesma linha no Visual Basic

É considerado má prática usar dois pontos para colocar duas instruções na mesma linha no Visual Basic?

Não há nada de errado em usar os dois pontos para combinar instruções. Isso realmente depende do contexto, mas, desde que não reduza a legibilidade, não há nada de errado com isso.

Como regra geral, evito usar o cólon para esse propósito. Eu acho que é mais legível ter uma declaração por linha. No entanto, isso não é um problema específico do cólon. Eu evito fazer o mesmo com um ponto e vírgula em C # ou C ++. É apenas uma preferência pessoal.

É uma boa prática com moderação, porque às vezes a legibilidade é aprimorada pela concatenação de duas linhas:

  • quando as linhas são curtas e intimamente relacionadas
  • quando as linhas são curtas e triviais

    Option Compare Database: Option Explicit ''My favorite! rsDataSet.Close: Set rsDataSet= Nothing 

Não faça isso se:

  • dói a legibilidade.
  • complica a debugging. Estruturas de controle como If...Then precisam ficar limpas. Você ficará feliz em saber que é simples quando é hora de definir um ponto de interrupção.
  • compromete a edição futura. Muitas vezes você quer manter as seções portáteis. Mover ou reestruturar um bloco de código é facilmente dificultado por tentativas de minimizar seu código.

Em geral, eu aconselharia contra isso, como faz para o código mais ocupado.

No entanto, para tarefas simples, não há nada de errado com isso. Por exemplo:

 for i = 1 to 10: ProcessFoo(i): next 

Eu acho que uma linha como esta é curta o suficiente para não causar confusão.

Eu vou pegar o outro lado. Eu não gosto de linhas densas de código. É mais fácil analisar o código quando as linhas não estão combinadas.

A combinação de instruções também facilita a criação de funções longas que ainda cabem em uma única canvas.

Não é um grande pecado, eu simplesmente não gosto disso.

Eu também não gosto de uma linha Se declarações.

Para mim você não deveria dizer “nunca faça assim”, você deveria apenas dizer “Se você fizer isso, um possível problema é tal e tal.” Então, basta pesar os prós e contras por si mesmo. O pro é brevidade / poucas linhas de código. Às vezes isso pode ajudar na legibilidade. Por exemplo, algumas pessoas usam para fazer declarações vb.Net:

 Dim x As Long: x = 1 

Ou espere loops:

 Do Until IE.ReadyState = READYSTATE_COMPLETE: DoEvents: Loop 

Mas, obviamente, você também pode tornar isso difícil para alguém:

 Public Sub DoYouKnowWhatThisDoes() MsgBox Example End Sub Private Function Example() Const s$ = "078243185105164060193114247147243200250160004134202029132090174000215255134164128142" Const w% = 3: Const l% = 42: Dim i%, r$: For i = 1 To l Step w: r = r & ChrW$(Mid$(s, i, w) Xor Mid$(s, i + l, w)): Next: Example = r End Function 

Outro motivo prático que você pode não querer usar essa abordagem é pontos de interrupção. Pontos de interrupção só podem ser definidos pela linha. Então, se você tem várias coisas executando na mesma linha, você não pode isolar a segunda coisa. Parará na primeira declaração. (Esta é também uma das razões pelas quais algumas pessoas não gostam de ifs de linha única.) Isso só complica a debugging um pouco.

Eu geralmente não uso dois pontos no código de produção por esse motivo. No entanto, eu os uso para melhorar a brevidade do código “copiar / colar” que publico em fóruns e em outros lugares. YMMV 🙂

Eu só usei isso quando estou gravando um conjunto de registros e definindo a variável para nada. Eu acho que uma linha em vez de duas me dá mais linhas de código na canvas e não diminui a legibilidade.

Eu vi isso usado em casos selecionados simples, como o seguinte, mas isso seria tanto quanto eu iria.

  Select Case success Case ERROR_FILE_NO_ASSOCIATION: msg = "no association" Case ERROR_FILE_NOT_FOUND: msg = "file not found" Case ERROR_PATH_NOT_FOUND: msg = "path not found" Case ERROR_BAD_FORMAT: msg = "bad format" 

de http://vbnet.mvps.org/index.html?code/system/findexecutable.htm

E mesmo assim eu teria alinhado a porção “msg =”.

Eu sei que essa é uma pergunta muito antiga, mas foi o primeiro resultado da minha pesquisa no Google, então espero ser perdoado por entrar aqui.

Existe uma situação (exatamente o que me levou aqui, na verdade) em que esta abordagem não é apenas útil, é a única maneira de alcançar o resultado desejado: a janela Imediata. Qualquer código que você queira executar na janela Immediate deve estar em uma linha. Portanto, para usar qualquer forma de Do, Case, For, While ou With na janela Immediate, você precisará usar dois pontos.

É considerado uma prática ruim na maioria dos sites em que trabalhei. E pela maioria dos desenvolvedores VB com quem trabalhei. E na minha cabeça Se eu vir, admito que quase certamente mudaria. Digo “quase” porque admito que existe a possibilidade de encontrar um código que tenha sido melhor assim. Eu não espero ver isso na minha vida, no entanto.

Eu também não gosto de uma linha ** If ** s também.

Ambos são mais prováveis ​​ressacas dos dias de monitores VGA (640×480); isso não é desculpa hoje em dia.

Eu nunca vi isso mencionado em uma capacidade oficial em qualquer uma das empresas que trabalhei. Mas eu acho que usar excessivamente os dois pontos pode começar a tornar seu código menos legível e mais difícil de manter.

Eu costumo usá-los às vezes, por exemplo, ao verificar o cancelamento em um dos meus projetos recentes:

 If _bCancel Then Status = CancelProcess() : Return Status 

Colocando isso em manter meu código legível do que o bloco IF alternativa.

Mas pode ser levado longe demais, eu herdei recentemente um projeto que está repleto de exemplos de uso excessivo do cólon:

  Select Case GetStringValue(Index).Trim.ToLower Case "yes", "y" : GetBooleanValue = True Case "no", "n" : GetBooleanValue = False Case Else : GetBooleanValue = Nothing End Select 

Pessoalmente acho que o acima é um pouco demais.

Eu vi isso usado em declarações de class ao usar inheritance ou implementar uma interface:

 Public Class DerivedClass : Inherits BaseClass ... End Class 

Mas, como os outros, também desestimulo seu uso.

Chris

eu gosto deste

 Using pro As New Process() : With pro ... End With End Using 

A resposta para a pergunta é Não. Qualquer coisa além de Não é puramente subjetiva e desperdiçadora, independentemente da resposta fora de um simples Não. Abaixo está o meu desperdício de digitação.

Você é algum tipo de escravo? Faça como quiser. Você é o centro do seu universo e não um estranho do StackOverflow. Se você trabalha para uma empresa, a pergunta é silenciosa porque o estilo de codificação já estaria definido e completamente fora de seu controle. Quanto a si mesmo, quem neste universo está indo para sempre em toda a eternidade, olhe para o longo cuidado com o seu código.

Eu escolheria A sobre B. Como evidencia isso mostra o propósito de um cólon sem o uso de um cólon. É para economizar espaço. Abaixo economiza espaço e torna o código muito mais legível. Mantém Simples Estúpido. O mesmo que ternário? : uso. Quando o código é inerentemente complexo, então um cólon, uma única linha se então outra coisa, ou um ternário, não deve mais ser considerado.

 '================================================================ 'A If somevalue1 = 0 Then AddLogTry("True") Else AddLogFalse("False") If somevalue2 = 0 Then AddLogTry("True") Else AddLogFalse("False") If somevalue3 = 0 Then AddLogTry("True") Else AddLogFalse("False") '================================================================ '================================================================ 'B If somevlaue1 = 0 Then AddLogTrue("True") Else AddLogFalse("False") EndIf If somevlaue2 = 0 Then AddLogTrue("True") Else AddLogFalse("False") EndIf If somevlaue3 = 0 Then AddLogTrue("True") Else AddLogFalse("False") EndIf '================================================================