¿Por qué me sale la advertencia del compilador

Identificador De La Lógica.DomainObjectBase._isNew’ no es compatible con CLS

para el siguiente código?

public abstract class DomainObjectBase
{
    protected bool _isNew;
}
  • Usted probablemente no debería estar marcado no-miembros privados con un carácter de subrayado de todos modos. Sé que cada uno tiene su propio estilo, pero otros casi sin duda creo que el campo es privado fuera de convenio.
  • Que el convenio?
  • Parece haber sido un VB convención a la vez, también parece estar fuera de estilo para C++, C#, más detalles de los que caben en este cuadro se encuentra aquí: stackoverflow.com/questions/3136594/…
  • Es común que a nombre de un miembro privado con un subrayado. Creo que fieldName es más común en C# (al menos, es lo que veo más a menudo que no), pero a algunos no les gusta, incluido yo mismo, porque te obliga a escribir this. por todo el lugar.
  • CamelCase para private/protected miembros es lo que MSDN general de las convenciones de nomenclatura sugiere para C#: . Presumiblemente, esta cuestión es una de las razones por qué. No he encontrado a muchas personas que usan un subrayado para indicar que un miembro privado, pero, presumiblemente, eso es porque yo uso principalmente de C# y C++ (que a veces es evitado debido a la la biblioteca estándar de reglas sobre el uso de guiones).
  • En realidad, no: msdn.microsoft.com/en-us/library/ms229012(v=vs 110).aspx. «Internas y campos privados no están cubiertos por las directrices». Te refieres a los miembros estáticos, una bestia diferente por completo. También, no hay nada malo con el uso de una sola subrayado por privado identificadores que son seguidos por una letra minúscula en C++. Nada en el espacio de nombres global o seguido por un capital, sí.
  • No me estaba refiriendo a los miembros estáticos, si lees el enlace que me envió, se sugiere el uso de PascalCasing, me dijo camelCasing. Me refería a la elección de la palabra convenios que advierten contra el uso de caracteres no alfanuméricos. Las directrices no explícitamente dar una regla para los miembros del sector privado, pero el nombre de los campos privados deben ser influenciado por el general convenciones de nomenclatura. Como para C++ es cierto que no prohibir subrayado-camelCasing, pero muchas personas prefieren evitar el líder pone de relieve en conjunto como una medida de precaución.

8 Comentarios

  1. 80

    De la Common Language Specification:

    Compatibles con CLS, los compiladores de lenguaje deben seguir las reglas del Anexo 7 del Informe Técnico 15 de la Norma Unicode 3.0, que regula el conjunto de caracteres que puede iniciar y ser incluidos en los identificadores. Este estándar está disponible en el sitio Web de Unicode Consortium.

    Si mira esto:

    Que es, el primer carácter de un identificador puede ser una letra mayúscula, letra minúscula, titlecase carta, modificador de la carta, otra letra o número de la carta. Los caracteres posteriores de un identificador puede ser cualquiera de los que, además de marcas sin espacio, el espacio de la combinación de marcas, números decimales, conector de puntuaciones, y los códigos de formato (como derecha-izquierda-mark). Normalmente los códigos de formato debe ser filtrada antes de almacenarlos o la comparación de los identificadores.

    Básicamente, usted no puede iniciar un identificador con un carácter de subrayado -, lo que infringe compatible con CLS en un lugar visible (público/protegido) de campo.

  2. 40

    Compatibilidad con CLS tiene que ver con la interoperabilidad entre los distintos .NET idiomas. La propiedad no es compatible con CLS, ya que comienza con un carácter de subrayado y es público (nota: los inmuebles protegidos en una clase pública se puede acceder desde fuera de la asamblea). A pesar de esto funcionará si se accede a la propiedad desde C# es posible que no se si se accede a ella a partir de otra .NET idiomas que no permiten que pone de relieve al principio de los nombres de propiedad, por lo tanto no es compatible con CLS.

    Usted está recibiendo este error del compilador, porque en algún lugar en su código que han marcado su asamblea como CLS compatible con una línea algo como esto:

    [assembly: CLSCompliant(true)]

    Visual Studio incluye esta línea en el archivo AssemblyInfo.cs archivo que se puede encontrar en Propiedades en la mayoría de los proyectos.

    Para evitar este error puede:

    1. Cambiar el nombre de tu propiedad (recomendado):

      protected bool isNew;
    2. Su conjunto a toda la asamblea a ser no compatible con CLS:

      [assembly: CLSCompliant(false)]
    3. Agregar un atributo sólo de su propiedad:

      [CLSCompliant(false)]  
      protected bool _isNew;
    4. Cambiar el ámbito de la propiedad, por lo que no puede ser visto fuera de la asamblea.

      private bool _isNew;
    • Así que, cuando usted tiene una propiedad pública con un protegidas variable, ¿cuál es la mejor convención?
    • Personalmente me gusta hacer todos los campos privados. Si necesito aumentar el alcance de la envolvía en una Propiedad Get/Set.
    • Hay muchas situaciones en las que una clase tiene una propiedad pública cuya setter llama a un método protegido, que los procesos de actualizaciones, pero donde los tipos derivados podría haber una necesidad legítima para usar el campo directamente y publicar actualizaciones después (por ejemplo, si una clase derivada de un control tiene un método para cambiar su color y la leyenda, pero la base no es así, puede ser útil para la clase derivada a cambiar en ambos campos y, a continuación, llame al método update una vez). Mi inclinación sería el uso de «Carácter» y «_characteristic», ya que ambos VB.NET y C# aceptarlo. ¿Qué sugeriría usted?
    • En mis 13 años de programación de tiempo completo .Neta yo no creo que pueda recuerdo nunca haber necesaria para hacer eso. Pero si yo no me iría a por un camelCase nombre de campo sin subrayado.
    • Un nombre de campo que coincide el nombre de la propiedad, excepto para el caso no sólo sería compatible con CLS, sino que haría que los identificadores inutilizable en VB.NET.
    • no tienen que tener el mismo nombre characteristicInternal por ejemplo. Pero realmente lo que usted está sugiriendo rompe la encapsulación. Desde el punto en el que publicar el código nunca se puede estar seguro de que el estado de ese campo de nuevo. Como tal, más bien me gustaría tener otro método o propiedad setter que el niño podría utilizar para realizar su actualización en su lugar.
    • El uso de un campo significa que el padre tendrá que confiar en el niño para cumplir su contrato. Por supuesto, las clases padres tienen que depender de los derivados de los niños a respetar sus contratos en otras formas, así que nada nuevo. Si una propiedad se utiliza, a continuación, a menos que el padre se compromete a no añadir nuevos comportamientos (en cuyo caso puede ser también de un campo), el niño no va a ser nunca seguro de lo que el padre va a hacer con él. Mucho depende realmente de la medida en que la clase de padre que existe para ocultar la aplicación de la clase derivada, frente a la medida para que…
    • …existe para hacer cosas que las clases derivadas podría haber hecho por sí mismos sin que hereda de la clase padre, de no ser por la necesidad de la clase derivada casos de identificación personal usando la base de la clase de referencias. Si el contrato para una clase base es muy específico acerca de lo que se supone debe hacer y cómo se supone que debe hacerlo, no hay mucho sentido en tratar de ocultar «los detalles de implementación», que no tienen la flexibilidad de todos modos.

  3. 28

    El líder subrayado concomitante con _isNew ser visible (es decir, no privado).

    • +1, Pero usted debe incluir el hecho de que el miembro es no privado, que, junto con el subrayado, hace que el nombre del miembro no Compatibles con CLS.
  4. 7

    El subrayado causa el problema. La práctica común es que el guión está reservado para los campos privados. protegido /miembros del sector público, debe estar correctamente embalado y con nombre.

    Por ejemplo:

    public abstract class DomainObjectBase{   
       private bool _isNew;
       protected bool IsNew { get { return _isNew; } set { _isNew = value;} }
    }

    O, si desea utilizar 3.x y deshacerse del campo privado:

    public abstract class DomainObjectBase{   
       protected bool IsNew { get; set; }
    }
    • Gracias! Me gustaría que marca este como el 2do mejor respuesta si pudiera.
  5. 2

    Un compatibles con CLS identificador no debe comenzar con un carácter de subrayado.

  6. 1

    El _ no es compatible con CLS

    Microsoft StyleCop va a analizar el código, y proporcionar enlaces a la importancia de los documentos que explican por qué no es compatible con CLS.

    • Me gusta la idea de StyleCop, pero sus reglas de conflicto con FxCop reglas, Resharper del reformatter y Visual Studio reformatter.
    • StyleCop y FxCop son producidos por Microsoft (aunque por diferentes equipos de producto) sin embargo, creo que StyleCop es la posterior, y por lo tanto más preferido uno si desea utilizar una «Microsoft» estilo de código.
  7. 0

    Porque el nombre del miembro de datos, _isNew, comenzar con un carácter de subrayado.

Dejar respuesta

Please enter your comment!
Please enter your name here