2010-10-22 8 views
21

Per quanto posso dire, è possibile accedere a qualsiasi membro statico di una classe come String o Int32 dal tipo di dati primitivi correlato. Quindi, String.Format è lo stesso di string.Format e Int32.MaxValue è lo stesso di int.MaxValue.Qual è la differenza tra String.Format e string.Format (e altri membri statici di tipi di dati primitivi)?

C'è una differenza tra queste due forme? Si preferisce l'altro? Anche se sono identici, è generalmente considerato più leggibile?

Modifica: Dal momento che sono identici, uno è preferito dal punto di vista umano? Preferiresti vedere String.Format o string.Format mentre leggi il codice di qualcun altro?

risposta

38

Non c'è alcuna differenza, questi sono alias di tipo in C# per i tipi di framework .Net, stai chiamando lo stesso metodo sotto.

Ad esempio:

  • int è un alias per System.Int32
  • string è un alias per System.String

You can find a complete list of these aliases on MSDN here.

+0

Cool, mi piace. Grazie per il link! –

+0

@Matthew - welcome :) –

+1

Quando stavo imparando C# ero un po 'confuso sul motivo per cui "stringa" e "stringa" esistevano entrambi. Mi ha aiutato a ingannare le cose quando ho capito che se ho rimosso la linea 'using System;' che "String" è diventato un tipo non valido. – Detmar

4

Sono identici. string e int sono alias sintattici rispettivamente per String e Int32.

2

stringa non è un tipo primativo ma semplicemente un alias per String. Sono la stessa cosa.

11

Questi non sono tipi di dati primitivi relativi a . Sono semplicemente abbreviazioni disponibili in C#. string alias System.String e int alias System.Int32. Le chiamate a int.MaxValuesono chiamate a Int32.MaxValue. C# consente solo di digitarla in modo simile a ciò che si digiterà se si fosse in un altro linguaggio simile a C.

3

Si noti che se si va nel vostro IDE e passa il mouse sopra string, si vedrà che è definito da System.String

Si tratta di un "alias" ... una cosa è una scorciatoia per un'altra cosa . int è un alias per Int32, byte è un alias per Byte, char è un alias per Char, e così via e così via.

8

La maggior parte delle risposte lo ha in generale. TUTTAVIA, ci sono alcuni casi in cui è richiesto l'alias. In cima alla mia testa:

public enum MyEnum:Byte {...} //will not compile 

public enum MyEnum:byte {...} //correct 

Ci sono un paio di altri posti in cui è necessario utilizzare l'alias; oltre a ciò, è per lo più stile.Le due regole seguenti sono generalmente accettati, forse il primo più del secondo:

  • Utilizzare l'alias (parola minuscolo) per tutti gli utilizzi di che definiscono un tipo di variabile o elemento (dichiarazione, parametri, colata, tipo chiusura generico
  • Utilizzare il nome tipo (identificatore di classe PascalCased) per tutti gli utilizzi del tipo in contesto statico (chiamata metodi statici come parser o metodi di manipolazione delle stringhe o proprietà statiche come MinValue/MaxValue).
3

Una prova divertente per la loro intercambiabilità è l'IDE stesso.
Iniziare a digitare List<String> list = new quindi esaminare il suggerimento di IntelliSense: List<string>. Non ti darà nemmeno List<String> come una delle scelte.

rispondere alla seconda parte della tua domanda, che è una questione parere, preferisco int e string over maiuscole per molte ragioni:

  • Il colore blu brillante è più definitivo e se siete codice veloce-lettura non si può confondere il nome della classe per qualcos'altro
  • il minore che ho bisogno di colpire SHIFT +, il più veloce di tipo i
  • IntelliSense si auto-completa i nomi minuscole, anche se si inizia con lettere maiuscole , quindi per me è esteticamente spiacevole vedere la versione maiuscola e minuscola ns della stessa classe nella stessa linea, o anche nello stesso progetto
  • Il tipo int è di natura molto semplice, e mi dispiacerebbe forzare i miei occhi ad associare quello con una lettera maiuscola e due cifre in il suo nome (es Int32); che lo fa apparire troppo specifico per nessuna ragione evidente

Un mio collega ha detto specificamente utilizzando Int32 e String garantisce la compatibilità con i futuri aggiornamenti .NET; Non sono d'accordo con chi lo dice completamente. Dimostrami che ho torto, per favore!

Problemi correlati