¿Debería usar el modificador de acceso privado si es redundante?

Question

Dado que estos dos ejemplos son equivalentes, ¿cuál cree que es preferible?

Sin modificador explícita

public class MyClass 
{ 

    string name = "james"; 

    public string Name { 
     get { return name; } 
     set { name = value; } 
    } 

    void SomeMethod() { ... } 

} 

Con modificador explícita

public class MyClass 
{ 

    private string name = "james"; 

    public string Name { 
     get { return name; } 
     set { name = value; } 
    } 

    private void SomeMethod() { ... } 

} 

---

Siempre he utilizarse esta categoría, pero recientemente he empezado a adoptar el estilo anterior. El privado es redundante, ya que es el modificador de acceso predeterminado, así que ¿no tiene sentido excluirlo?

Answer 1

Creo que la explicidad que indica ayuda privada en la legibilidad. No permitirá que un programador interprete su visibilidad de manera diferente.

Answer 2

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. :-)

Answer 3

estás en lo correcto, pero ya que usted quiere que su código sea comprensible para todo el mundo, creo que debe incluir, nunca se sabe cuando si alguien no lo sabe

Answer 4

Personalmente, prefiero el modificador privada - I como explicito 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).

Answer 5

Utilice 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. P.ej. en C#, los campos struct predeterminados a public, los campos de clase predeterminados a private, y las definiciones de clase predeterminadas a internal.

Answer 6

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 correcto 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!

Answer 7

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 alinean mejor :)

Answer 8

Marcarlo como privado deja en claro que es deliberado, en lugar de "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; tipos anidados son privados por defecto ...

Deje claro ... ;-P hacen explícita

Answer 9

Siempre omitirlo para reducir el desorden visual. En C#, todo lo predeterminado es con 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 esté más visible, luego agregue el modificador. Esto facilita ver elementos que se desvían de la visibilidad predeterminada.

El único caso 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 el contrario, casi siempre lo incluyo porque los valores predeterminados son bastante estúpidos; el valor predeterminado para un Sub o Función es Friend en lugar de Private.

Answer 10

Siempre especifico explícitamente la visibilidad. Prefiero no dejar que el compilador adivine mis intenciones.

Answer 11

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.

Answer 12

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 es NOT privada pero pública, por ejemplo PHP.

Answer 13

Parece que somos el único, pero personalmente, Apoyo eliminemos la campaña privada.

Mi preocupación es que tanto públicas como privadas son tan similares, 6-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 explícitos privados que entre 10 que no tienen acceso atributo.

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 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 en un matemático cuando el código es explícito para preservar la ignorancia futura del codificador. Ese es el modo VB, no C# ...

Answer 14

Primero preguntaré si hay una convención/estándar de código anterior sobre eso que está siendo utilizado por el equipo. Si hay alguno, deberías seguirlo.

Si tiene que definir la convención, lo presionaré de manera explícita.

¿Mis razones ?;

• Me gusta mantener la misma estructura (me refiero a a-access modifier, b.-return-type/type, c.-name).
• No quiero (y no espero que otros) recordar todos los modificadores por defecto (which are here).
• 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 los mismos. 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.