Come evitare di sprecare spazio sullo schermo scrivendo codice C# sparse?

Question

Il modo comunemente accettato per formattare C# codice sembra essere come segue:

namespace SomeNamespace 
{ 
    namespace SomeSubNamespace 
    { 
     class SomeClass 
     { 
      void SomeFunction() 
      { 
       using (var someFile = new StreamWriter(somePath)) 
       { 
        try 
        { 
         lock(someCriticalSection) 
         { 
          using (var someDisposableThing1 = new DisposableThing()) 
          { 
           DoSomething();        
           using (var someDisposableThing2 = new DisposableThing()) 
           { 
            lock(someOtherCriticalSection) 
            { 
             DoSomethingMore(); 
            } 
           } 
          } 
         } 
        } 
        catch(Exception e) 
        { 
         Log(e); 
        } 
      } 
     } 
    } 
} 

Questo spreca una grande quantità di spazio sullo schermo, sia orizzontalmente che verticalmente. Non sono sicuramente la prima persona che nota. La mia domanda è: ci vivi o hai sviluppato uno stile di formattazione diverso per evitare un eccesso di spazio bianco?

PS: Nota che non ho nemmeno usato una sola istruzione if!

Answer 1

Io tendo a scrivere classi piccole, metodi brevi con un livello piccolo di annidamento. Non solo puoi vedere tutto sul tuo schermo, anche il codice è migliore!

Answer 2

Ho un 24" widescreen monitor. Io preferisco di gran lunga 'pretty-printing' over recuperare lo spazio. Abbreviato, il codice stipati-insieme è difficile da leggere e fa male il mio cervello.

Answer 3

1. Non mi capita spesso vedi namespace annidati in quel modo - forse succede, non dove lavoro
2. Io vivo con esso. E soprattutto non scrivo codice così profondamente annidato. Avere metodi più brevi, o metodi con meno nesting, certamente riduce il problema degli spazi bianchi orizzontali e avere metodi suddivisi in parti più piccole significa che puoi ottenere informazioni più importanti in una determinata quantità di spazio verticale

Answer 4

Beh ho comprato un monitor HD;)

Ma l'unico modo per affrontare lo distingue da utilizzando meno rientro sarebbe quello di spostare un po 'di codice nei propri metodi.

Answer 5

Se ho intenzione di provare/catturare qualcosa, vorrei combinare con qualsiasi adiacente utilizzando blocchi. Allo stesso modo, vorrei aggregare spazi dei nomi, quindi qualcosa di più vicino:

namespace SomeNamespace.SomeSubNamespace 
{ 
    class SomeClass 
    { 
     void SomeFunction() 
     { 
      StreamWriter someFile; 
      try 
      { 
       someFile = new StreamWriter(somePath); 

       lock(someCriticalSection) 
       { 
        using (var someDisposableThing1 = new DisposableThing()) 
        { 
         DoSomething();        
         using (var someDisposableThing2 = new DisposableThing()) 
         { 
          lock(someOtherCriticalSection) 
          { 
           DoSomethingMore(); 
          } 
         } 
        } 
       } 
      } 
      catch(Exception e) 
      { 
       Log(e); 
      } 
      finally 
      { 
       if(someFile != null) 
       { 
        someFile.Dispose(); 
       } 
      } 
     } 
    } 
} 

Answer 6

non credo che sembra così male;) disporre delle funzioni più brevi ma in realtà è un punto. In particolare, è bello se si può fare cose come la sostituzione

if (condition) 
{ 
    // bla 
} 
else 
{ 
    // blub 
} 

da

void someFunction() 
{ 
    if (condition) 
    { 
    // bla 
    return 
    } 
    // blub 
} 

Answer 7

Mi spiego in questo modo. Se ti capita davvero di incontrare un costrutto di codice annidato così profondo come quello che mostri sopra, il problema probabilmente non è la formattazione ma la struttura del codice.

Si dovrebbe considerare dare un'occhiata a questo: Refactoring by Martin Fowler

Con extracting methods a migliorare non solo il "sprecato" spazio sullo schermo, ma si aumenta notevolmente la leggibilità troppo;)

Un'altra soluzione è sempre: Alt +Maiusc +Inserisci in Visual Studio per entrare in modalità a schermo intero

Answer 8

Sono d'accordo con le altre risposte che fondamentalmente vivo con esso - per il mio team abbiamo monitor ad alta risoluzione o due monitor (o entrambi), quindi non è come stiamo sviluppando su 800x600.

Ma una cosa da tenere a mente è che il vostro tabulazione sarebbe meglio se si è utilizzato distanza effettiva, come alcuni sviluppatori di utilizzare 2 spazi per una scheda, alcuni 4, alcuni 6. Così, mentre il codice formattato può sembrare bene su una IDE dello sviluppatore, potrebbe non sembrare così bello da un altro. (Ho visto alcuni risultati orribili da questo.)

VS2010 ha un bel plug-in da Gestione estensioni chiamato Strumenti di produttività che rileva quando si ha un mix di schede e spazi nel file e consente di convertire tutto a schede o spazi ("Correggi le schede miste"). Aiuta davvero a ripulire il tuo file (anche se non sembra che faccia qualcosa!). È fantastico se condividi il codice tra i team.

Answer 9

Strumenti> Opzioni> Editor di testo> All Languages> Schede> dimensioni rientro> 1
Non una grande soluzione ...: P

Answer 10

uso CodeRush, si farà la navigazione attraverso il vostro codice di molto meglio

si otterrà qualcosa di simile

Answer 11

ho visto parentesi aperte sulla linea all'inizio di un blocco di codice come in:

namespace SomeNamespace { 
    class SomeClass { 
     void SomeFunction() { 
      using (var someFile = new StreamWriter(somePath)) { 
       try { 
        lock(someCriticalSection) { 
         using (var someDisposableThing1 = new DisposableThing()) { 
          DoSomething();        
         } 
        } 
       } catch(Exception e) { 
        Log(e); 
       } 
      } 
     } 
    } 
} 

Meno immobiliare, ma penso che sia brutto.

Answer 12

Si consiglia di leggere Clean Code di Bob Martin. Aiuta con questo problema. In questo caso, SomeFunction() fa più di una cosa. Dividi ogni cosa che fa nel suo stesso metodo.

namespace SomeNamespace.SomeSubNamespace 
{ 
    class SomeClass 
    { 
     void WriteToFile() 
     { 
      using (var someFile = new StreamWriter(somePath)) 
      { 
       lock(someCriticalSection) 
       { 
        ExecuteCriticalSection(); 
       } 
      } 
     } 
     void ExecuteCriticalSection() 
     { 
      using (var someDisposableThing1 = new DisposableThing()) 
      { 
      DoSomething(); 
      ExecuteFinalCriticalSection(); 
      } 
     } 

     void ExecuteFinalCriticalSection() 
     { 
      using (var someDisposableThing2 = new DisposableThing()) 
      { 
      lock(someOtherCriticalSection) 
       { 
       DoSomethingMore(); 
       } 
      } 
     } 
    } 
} 

Inoltre, non prendere uno System.Exception; non sai mai cosa fallirà e non dovresti cercare di individuare le eccezioni che non puoi gestire. Lasciali gonfiare e morire orribilmente.

Answer 13

In aggiunta a ciò che altri hanno detto qui, l'unica cosa che faccio per attenuare l'effetto è usare un carattere con spaziatura proporzionale. Il testo è più leggibile, ma non altrettanto ampio. Ti costringe anche a usare tabulazioni sopra gli spazi per l'allineamento (che è, naturalmente, perché il buon Dio ci ha dato schede in primo luogo)

Personalmente uso Comics Sans MS, ma che guida davvero i colleghi pazzi ....

Answer 14

L'istruzione using è molto utile, ma se il codice diventa più difficile da leggere si può fare a meno:

namespace SomeNamespace.SomeSubNamespace 
{ 
    class SomeClass 
    { 
     void SomeFunction() 
     { 
      StreamWriter someFile = new StreamWriter(somePath); 
      DisposableThing someDisposableThing1 = null; 
      DisposableThing someDisposableThing2 = null; 

      try 
      { 
       lock (someCriticalSection) 
       { 
        someDisposableThing1 = new DisposableThing(); 
        DoSomething(); 
        someDisposableThing2 = new DisposableThing(); 
        lock (someOtherCriticalSection) 
        { 
         DoSomethingMore(); 
        } 
       } 
      } 
      catch (Exception e) 
      { 
       Log(e); 
      } 
      finally 
      { 
       // requires SafeDispose extension method 
       someFile.SafeDispose(); 
       someDisposableThing1.SafeDispose(); 
       someDisposableThing2.SafeDispose(); 
      } 
     } 
    } 
} 

Answer 15

alcune idee generali:

• combinare questi blocchi dello spazio dei nomi in una sola.
• Raccogliere le dichiarazioni using in un posto, se è possibile.
• Se non sei un fanatico "Anche le singole istruzioni devono includere {} s!", è possibile eliminare le parentesi tra i blocchi using e try..catch.
• Pensa se i nidificati di lock s sono realmente necessari o se il più esterno lock è sufficiente.

Questi potrebbe risultato nel codice seguente (prendere atto che il significato del codice esempio ipotetico potrebbe non essere esattamente conservato):

namespace SomeNamespace.SomeSubNamespace 
{ 
    class SomeClass 
    { 
     void SomeFunction() 
     { 
      using (var someFile = new StreamWriter(somePath)) 
      try 
      { 
       lock(someCriticalSection) 
       { 
        using (var someDisposableThing1 = new DisposableThing()) 
        using (var someDisposableThing2 = new DisposableThing()) 
        { 
         DoSomething();        
         DoSomethingMore(); 
        } 
       } 
      } 
      catch(Exception e) 
      { 
       Log(e); 
      } 
     } 
    } 
} 

(si potrebbe anche spostare i due using s per l'altra dichiarazione using al di fuori dello lock, se il codice lo consente.È inoltre possibile sostituire le istruzioni using con chiamate esplicite a Dispose in un blocco finally, come suggerito in un'altra risposta.)