otra - diferencia entre private y protected c#
¿Deberías usar el modificador de acceso privado si es redundante? (14)
Dado que estos dos ejemplos son equivalentes, ¿cuál crees que es preferible?
Sin modificador explícito
public class MyClass
{
string name = "james";
public string Name {
get { return name; }
set { name = value; }
}
void SomeMethod() { ... }
}
Con modificador explícito
public class MyClass
{
private string name = "james";
public string Name {
get { return name; }
set { name = value; }
}
private void SomeMethod() { ... }
}
Siempre he usado este último, pero recientemente comencé a adoptar el estilo anterior. El privado es redundante, ya que es el modificador de acceso predeterminado, así que ¿no tiene sentido excluirlo?
Creo que la explicidad de las ayudas privadas ayuda a la lectura. No permitirá que un programador interprete su visibilidad de manera diferente.
Marcarlo como privado deja en claro que es deliberado, en lugar de "en realidad no lo pensé, así que no sé si sería mejor como algo más"; así que me gusta hacerlo explícito. Sin embargo, no me haría religioso al respecto.
Además, esto evita tener que recordar las reglas ... los miembros son privados por defecto, los tipos (externos) son internos por defecto; los tipos anidados son privados por defecto ...
Dejar en claro ... hacerlo explícito ;-p
Mi comprensión siempre ha sido que los miembros tienen acceso "interno" a menos que se indique lo contrario. Si eso es cierto, se requerirá el modificador "privado" para garantizar que esos miembros sean de hecho privados.
Independientemente de si estoy en lo cierto sobre lo anterior o no, dejar el modificador en su lugar aumentará la legibilidad del código en caso de que otro desarrollador modifique esta clase más adelante y tenga curiosidad sobre la accesibilidad. ¡Espero que esto ayude!
Personalmente, prefiero el modificador privado: me gusta la claridad. Para los campos, también resalta que es una variable miembro en oposición a una variable de función (la única diferencia es la ubicación, que está bien si la gente puede sangrar correctamente, pero puede ser confusa de lo contrario).
Siempre especifico la visibilidad explícitamente. Prefiero no dejar que el compilador adivine mis intenciones.
Siempre prefiero ser explícito, incluso si es redundante. Esto proporciona comentarios de código integrados y puede ser útil para el siguiente tipo, especialmente si es un novato. :-)
Usa siempre el formulario explícito. Si por alguna razón el supuesto subyacente cambia, el código con una denotación explícita de acceso no se romperá, mientras que la connotación implícita se romperá fácilmente.
Además, cuando se habla de diferentes tipos de estructuras, pueden tener diferentes accesibilidades predeterminadas. Sin los modificadores explícitos, el propio lector está en el lector para saber qué estructura tiene qué valor predeterminado. Por ejemplo, en C #, los campos struct predeterminados en public , los campos de clases predeterminados en private y las definiciones de clases predeterminadas en internal .
Voy explícito todo el tiempo. Si nada más demuestra su intención más claramente. Si quiero que algo sea privado, lo diré. Escribir explícitamente el modificador me asegura que lo pienso, en lugar de simplemente dejar las cosas en privado porque es más rápido. Que una larga lista de miembros se alineen mejor :)
tienes razón, pero como quieres que tu código sea comprensible para todos los que creo que debes incluir, nunca sabes cuándo alguien no sabe esto
He estado desarrollando a tiempo completo en C # durante aproximadamente 7 años, y hasta que leí este tema no sabía cuál es el modificador de acceso predeterminado. Sabía que existía uno, pero nunca lo he usado.
Me gusta declarar explícitamente mi intención mientras codigo. Tanto porque las declaraciones están ahí para que las vea cuando vuelvo y las miro, y porque realmente pensar y escribir la palabra "privado" cuando escribo un método me hace pensar un poco más sobre lo que tengo en mente para hacer.
Me gusta ser super-explícito por lo general. Iré por especificar "privado" siempre. Sin embargo, hay otra razón: los programadores provienen de lenguajes de programación donde la visibilidad predeterminada NO es privada sino pública, por ejemplo PHP.
Siempre lo omito para reducir el desorden visual. En C #, todo se predetermina a la menor visibilidad posible . Un miembro de la clase (campo, método, propiedad) se predetermina a privado. Una clase predeterminada es interna. Una clase anidada es por defecto privada.
Si necesita que algo sea más visible, agregue el modificador. Esto facilita ver elementos que se desvían de la visibilidad predeterminada.
El único caso en el que puedo ver que causa problemas es si vienes de un fondo VB .NET. Pero bueno, vengo de un fondo VB .NET, y todavía sé cuáles son las visibilidades predeterminadas en C #.
En VB .NET, por otro lado, casi siempre lo incluyo porque los valores predeterminados son bastante estúpidos; el valor predeterminado para un Sub o Función es Friend lugar de Private .
Parece que somos el único, pero personalmente, apoyo la campaña privada.
Mi preocupación es que lo público y lo privado son tan similares, de 6 a 7 caracteres de longitud, azul, comenzando con ''p'', por lo que es mucho más difícil señalar un método público entre 10 privados explícitos que entre 10 que no tienen ningún atributo de acceso.
Además, es una ventaja ya que las personas perezosas en su equipo tienden a guardar la escritura del modificador y hacer que el método sea privado, lo que en realidad es algo bueno. De lo contrario, terminas con todo lo público.
Normalmente prefiero explícito sobre implícito, pero eso es más importante en los casos de esquina de lenguaje (trucos engañosos) que en una característica generalizada. Aquí creo que la mantenibilidad a largo plazo es más importante.
Además, normalmente me gusta cuando el código es simple y claro de forma matemática cuando el código es explícito para preservar la ignorancia futura del codificador. Esa es la forma VB, no C # ...
Primero preguntaré si hay una convención / estándar de código anterior sobre eso que usa el equipo. Si hay alguno, deberías seguirlo.
Si tiene que definir la convención, presionaré por la forma explícita.
Mis razones ?;
- Me gusta mantener la misma estructura (me refiero a un modificador de acceso, b.-return-type / type, c.-name).
- No quiero (y no espero que otros) recordar todos los modificadores por defecto ( que están aquí ).
- No todos los idiomas tienen las mismas reglas.
- Y de alguna manera creo que, de alguna manera, obliga al desarrollador a pensar y ser más consciente sobre el alcance de la variable / método y la exposición de aquellos. Si tienes algo de experiencia, probablemente no se aplique, pero si eres un novato o trabajas con personas con menos experiencia, creo que es útil.