Me gustaría saber los pros y los contras de los procedimientos de llamada con Call Keyword y sin Call in VB.NET?¿Cuáles son los pros y los contras de los procedimientos de llamada en VB.NET?
Private Sub ProOne()
// Code Are Here
End Sub
Private Sub Calling()
ProOne() // I would like to know pros and cons of this
Call ProOne() // And I would like to know pros and cons of this
End Sub
Gracias de antemano a todos.
De here:
normalmente utiliza la instrucción Call para llamar a un procedimiento que no un valor de retorno. Si el procedimiento devuelve un valor, la instrucción Call lo descarta.
No es necesario que utilice la declaración de llamada al llamar a un procedimiento . Sin embargo, mejora la legibilidad de tu código.
Por lo tanto, en esencia, ProOne() y Call ProOne() son semánticamente equivalentes.
No hay ventajas, y no hay inconvenientes.
La palabra clave Call es una palabra clave heredada de dialectos VB anteriores.
En VB.net no tiene ningún significado, y es azúcar sintáctica.
De la documentación
transfiere el control a una función, Sub, o biblioteca de vínculos dinámicos (DLL) procedimiento. [Llamada] ProcedureName [ (ArgumentList)]
así,
Normalmente se utiliza la instrucción de llamada a llamada un procedimiento que no devuelve un valor . Si el procedimiento devuelve un valor de , la declaración de llamada lo descarta.
No es necesario utilizar la instrucción Call al llamar a un procedimiento. Sin embargo, mejora la legibilidad de su código.
Aunque son técnicamente equivalentes, no estoy de acuerdo con el uso de "Llamar". Al pasar de VB6 a VB.Net, es importante darse cuenta de que son idiomas completamente diferentes que deben escribirse de maneras completamente diferentes. Desafortunadamente, Microsoft quería brindar soporte a los desarrolladores de VB6, y lo proporcionaron al agregar funcionalidad que imita la funcionalidad de VB6, pero es significativamente inferior al equivalente de .Net.
El corte de todos los vínculos con cualquiera de los remanentes de VB6 hará que los desarrolladores dejen de utilizar estos bits lo más rápido posible, y conducen a una mejor salida de código.
Aunque estoy de acuerdo contigo, no veo por qué alguien dispuesto a cortar todas las ataduras no use simplemente C# en lugar de VB.NET. La familiaridad de la sintaxis es prácticamente lo único que VB.NET tiene a su favor. – Dan
Un uso interesante que encontré (R#), fue cuando necesita crear una instancia solo para llamar a un único método y luego marcarlo para la recolección de elementos no utilizados.
No estoy seguro si lo estoy guardando bien.
Por ejemplo
Call (new MyType()).MySub()
equivalente de
dim anInstance = new MyType
anInstance.MySub
¿No sería más sucinto usar la instancia predeterminada? es decir, simplemente 'MyType.MySub()' – Michael
@Michael, que sugiere que usaría un método estático. El método no es estático. Creo que VB lo permite, pero es bastante confuso. Definitivamente cuando vienes de un C# bgnd. –
@BorisCallens Si no le está pasando nada al constructor, no veo cómo crear instancias de una nueva instancia es menos confuso que simplemente usar la instancia predeterminada. – Dan
"Sin embargo, se mejora la legibilidad del código". Depende del gusto personal, no puedo soportarlo por mi cuenta y nunca lo uso :) –