In C # usa stringhe costanti private meglio di usare le stringhe direttamente nel codice? [chiuso]

Question

In C # usa stringhe costanti private meglio di usare le stringhe direttamente nel codice? [chiuso]

#1 da (9 voti)
#2 da (7 voti)
#3 da (1 voti)
#4 da (1 voti)

6

Considera i seguenti due casi:

caso 1:

class A
{
    private const string MyConst="Hello";

    internal void CallMe()
    {
        System.Console.WriteLine(MyConst);
    }
}

Caso 2:

class A
{
    internal void CallMe()
    {
        System.Console.WriteLine("Hello");
    }      
}

Ora, se il metodo CallMe () fosse chiamato 1000 volte, è una buona idea definirlo come costante (che significa solo una copia della stringa per classe) o usare una stringa semplice sarebbe meglio. Ho appena controllato il codice MSIL per entrambe le classi e ho scoperto che in entrambi i casi, il compilatore .Net sta inserendo la stringa letterale all'interno di WiriteLine (). Quindi è un overhead definire la stringa come una costante?

Il motivo principale per cui ho fatto questa domanda è perché volevo capire come funziona il CLR quando qualcosa è definito come costante a livello di classe e quando ho visto che il codice MSIL aveva il campo const e anche la stringa in WriteLine () sostituito con la stringa vera e quindi mi chiedevo perché creare un campo costante se verrà usato in un solo metodo. Questo è solo un esempio di codice che ho scritto per presentare il mio dubbio. E dalle risposte che ho imparato dopo:

È preferibile utilizzare direttamente la stringa se non verrà utilizzata al di fuori del metodo
Se è usato in tutte le classi / classi, lo dichiari come costante a livello di classe
Inseriscilo in resex se ha bisogno di localizzazione

Grazie a tutti per le risposte / i commenti.

c# strings const

posta GawdePrasad 23.09.2015 - 11:24

fonte

4 risposte

Leggi altre domande sui tag c# strings const

Test delle unità più forti Scopri molti bug, cosa fare? Validazioni? Esiste una regola empirica per eliminare una storia dall'arretrato?

score 9 · Answer 1

Considerato che fare ciò come una prestazione non è ragionevole. Tuttavia, farlo per la leggibilità del codice è molto ragionevole. In un bit di codice non banale userei le costanti per aggiungere un significato sintattico alla variabile. Temete la stringa magica.

class GreetingPrinter
    {
        private const string Greeting = "Hello";

        internal void CallMe()
        {
            Console.WriteLine(Greeting);
        }
    }

Il prefisso c_str mi fa infrangere gli occhi e non aggiunge nulla alla leggibilità del codice.

score 7 · Answer 2

7

Case2 è migliore perché la stringa non ha più dello scope di cui ha bisogno e non devo inseguire variabili per leggere il tuo codice. Semplice. Le prestazioni non contano qui.

risposta data 23.09.2015 - 12:45

fonte

score 1 · Answer 3

Per dirla in un'altra direzione:

In caso di Hello è assurdo definire una costante e vorrei andare alla seconda soluzione. Ma diciamo che hai deoxyribonucleicacid e usalo più di una volta in una classe, opterei per una costante, quindi potresti sfruttare l'IDE / il compilatore per eseguire il controllo ortografico. Trovo che sia sempre un bel trucco.

score 1 · Answer 4

Sono in gran parte d'accordo con la risposta di Froome e farei qualcosa di simile nella maggior parte dei casi, ma penso che ci siano altre cose da considerare:

Per i valori che esistono solo nel metodo corrente, non tirare fuori il campo senza pensare. Tieni i dati vicino a dove sono usati ed estrai le cose quando è necessario per evitare la duplicazione. il Principio di Responsabilità Unico ci dice di tenere insieme le cose che cambiano per lo stesso motivo e di separare le cose che cambiano per ragioni diverse. Ciò semplifica l'estrazione di comportamenti da questa classe in nuove classi man mano che la complessità del tuo sistema cresce.

Per me tutto dipende dal tipo di stringa "Ciao". Se si tratta di un saluto da inviare a un utente in una GUI, dovrebbe essere estratto in una risorsa esterna. Se si tratta di un valore predefinito restituito dal metodo utilizzato da altri metodi all'interno della classe, direi di lasciarlo nel metodo finché non trovi un motivo valido per spostarlo da lì.

In breve, non assumere troppo prima di sapere come verrà utilizzato il valore. Guarda dove ti porta il tuo design e valuta costantemente se stai andando nella giusta direzione.

EDIT:

Un altro pensiero, se consideriamo il principio Aperto / Chiuso qualcosa di simile potrebbe essere appropriato:

public class A
{
    internal void CallMe()
    {
        Console.Out.WriteLine(GetGreeting());
    }

    protected virtual string GetGreeting()
    {
        return "Hello";
    }
}

Ciò consente al comportamento di essere modificato estendendo la classe ma mantenendo questa versione chiusa per le modifiche.

Anche in questo caso, indipendentemente dal fatto che questa sia la strada da percorrere, dipende dal tipo di sistema che stai costruendo e da come verrà utilizzato / modificato in futuro.