En C#, ¿hay alguna diferencia entre usar System.Object en el código en lugar de sólo object, o en lugar de System.Stringstring y así sucesivamente? ¿O es solo una cuestión de estilo?C#: diferencia entre "System.Object" y "objeto"
¿Hay alguna razón por la cual una forma es preferible a la otra?
string es un alias para global::System.String. Es simplemente azúcar sintáctica. Los dos son intercambiables exactamente en casi todos los casos, y no habrá diferencia en el código compilado.
Personalmente utilizo los alias de nombres de variables, etc, pero yo uso los nombres de tipos de CLR para los nombres de las API, por ejemplo:
public int ReadInt32() // Good, language-neutral
public int ReadInt() // Bad, assumes C# meaning of "int"
(Tenga en cuenta que el tipo de retorno no es realmente un nombre - Es codificado como un tipo en los metadatos, por lo que no hay confusión allí.)
Los únicos lugares que conozco donde se puede usar uno y el otro no (que yo sepa) puede es:
nameof prohíbe el uso de alias¡La observación sobre la neutralidad del lenguaje para las API públicas es muy interesante! –
Vale la pena hacerlo solo para cerrar FxCop –
La neutralidad del lenguaje para las API públicas es la cantidad de bibliotecas .NET que funcionan. – yfeldblum
Uno es un alias del otro. Se reduce al estilo.
string es un alias para global::System.String y object para global::System.Object
Siempre que tiene using System; en su clase, String/string y Object/object son funcionalmente idénticos y su uso es una cuestión de estilo.
(EDIT: slightly misleading quote eliminado, de acuerdo con el comentario de Jon Skeet)
"Cadena" con una letra mayúscula no tiene ningún significado para el compilador C# o el lenguaje C#. "cadena" * siempre * corresponde a global :: System.String. No sé de dónde sacó el autor original la noción de que "Cadena" tiene un significado especial. –
debido a Java – bobobobo
No hay diferencia. Hay una serie de tipos, llamados Primitive Data Types que son amenazados por el compilador en el estilo que usted mencionó.
El estilo de denominación en mayúsculas es la regla de denominación ISO. Es más general, común; fuerza las mismas reglas de denominación para todos los objetos en la fuente sin excepciones como el compilador C#.
Ese artículo está mal escrito para usar la palabra "primitivo" allí. Si mira los documentos para Type.IsPrimitive, verá: "Los tipos primitivos son Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Double y Single." Tenga en cuenta que este * no * incluye cadena, decimal y objeto, pero * does * include IntPtr y UIntPtr. –
(También usa la palabra "objeto" de una manera bastante rápida y suelta. Es un artículo generalmente mal escrito, IMO.) –
¿Quizás un término mejor sería "Tipos de datos de palabras clave"? –
Que yo sepa, sé que es un atajo, es más fácil usar una cadena, en lugar de System.string.
Pero tenga cuidado de que hay una diferencia entre la cadena y la cadena (C# entre mayúsculas y minúsculas)
¿Qué diferencia hay entre ellos? – abatishchev
Intenta usar "Cadena" sin un "sistema que usa"; directiva :) –
@Jon es muy cierto. – IamIC
string (con minúscula "s") es el tipo de cadena del lenguaje C# y el tipo System.String es la implementación de string en el marco de .NET.
En la práctica no hay diferencia además de las estilísticas.
EDITAR: Dado que lo anterior obviamente no era lo suficientemente claro, no hay diferencia entre ellos, son del mismo tipo una vez compilados. Estaba explicando la diferencia semántica que ve el compilador (que es simplemente azúcar sintáctica, muy similar a la diferencia entre un ciclo y un ciclo).
-1 Esto es incorrecto. string y System.String son completamente intercambiables. string es simplemente un alias para System.String –
Esto es correcto, y nunca dije que fueran diferentes. cadena es una palabra clave que apunta a System.String. Quizás no estaba claro. –
En realidad, estaba muy claro, "En la práctica no hay diferencia ..." –
El objeto tipo es un alias para System.Object. El tipo objeto se usa y se muestra como palabra clave. Creo que tiene algo que ver con el legado, pero eso es solo una suposición descabellada.
Echa un vistazo a esta página MSDN para más detalles.
Prefiero el uso de las versiones en minúscula, pero sin motivos especiales. El hecho de que el resaltado de sintaxis es diferente en estos tipos "básicos" y no tener que utilizar la tecla de mayúsculas al escribir ...
objeto, int , largo y bool fueron proporcionados como ruedas de entrenamiento para los ingenieros que tuvieron problemas para adaptarse a la idea de que los tipos de datos no eran una parte fija del idioma. C#, a diferencia de los idiomas anteriores, no tiene límite en la cantidad de tipos de datos que puede agregar. La biblioteca 'Sistema' ofrece un kit de inicio con tales tipos útiles como System.Int32, System.Boolean, System.Double, System.DateTime y así sucesivamente, pero se anima a los ingenieros para añadir su propia cuenta. Debido a que Microsoft estaba interesado en la rápida adopción de su nuevo idioma, proporcionaron alias que lo hicieron parecer como si el lenguaje fuera más parecido a "C", pero estos alias son una característica completamente desechable (C# sería un lenguaje tan bueno si eliminado todos los alias de compilación, probablemente mejor).
Si bien StyleCop impone el uso de los alias de estilo C heredados, es un defecto en un conjunto de reglas que de otro modo sería lógico. Hasta el momento, no he escuchado una sola justificación para esta regla (SA1121) que no se basó en el dogma. Si cree que SA1121 es lógico, ¿por qué no hay ningún tipo de buildin para datetime?
Así es como lo hago: utilizo int o string en el contexto de una variable primitiva (como int x = 0) y uso Int32 y String, etc. en el contexto de clases (como Int32.Parse o String.Empty) - no hace ninguna diferencia, sin embargo, al final se compila con el mismo tipo de CLR. –
¿por qué no publica eso como respuesta? –
Esta es una pregunta similar a esta: http://stackoverflow.com/questions/981434/can-anyone-give-me-a-really-good-reason-to-use-clr-type-names-instead- of-c-type – RichardOD