Ordinamento automatico di membri di classe / modulo e il suo possibile impatto sulla produttività e sulla qualità del codice [chiuso]

Trovo strano che tutti sembrino dire immediatamente "No" all'idea che l'IDE ordini automaticamente i membri di una classe. Lavorando in C # un po 'e rispettando le regole predefinite di StyleCop, personalmente trovo piacevole avere coerenza nel mio codice per avere tutti i campi, costruttori, proprietà e metodi raggruppati e all'interno di ogni gruppo è ordinato per ambito (pubblico, protetto, protetto interno, privato). Indietro prima che lo sviluppo si fermasse su di esso ho fatto uso di Regionerate per raggruppare automaticamente il codice per me e assicurarmi che i membri fossero in ordine alfabetico. Vorrei davvero che il mio team attuale ne vedesse i vantaggi, perché per un certo numero di classi base che tutti dobbiamo modificare (talvolta allo stesso tempo) con gli strumenti per strutturare in modo coerente i nuovi membri, renderebbe più facile unire una tonnellata.

Non penso che avrebbe un impatto positivo. Tendiamo a raggruppare i membri della classe in base al loro scopo e funzione, e questo è qualcosa che non può essere comunicato per mezzo di alcun criterio semplice: richiede una comprensione di ciò che effettivamente fa .

Ad esempio, in un codice scritto a mano, un metodo pubblico che manipola alcuni tipi di elementi e contiene una chiamata a una routine di libreria standard per ordinare gli elementi potrebbe essere immediatamente seguito dal metodo di callback privato che confronta tali elementi, in modo che il programmatore può considerare i due metodi nel loro complesso, poiché lavorano a stretto contatto tra loro. Non vedo alcun tipo di criterio che potrebbe essere utilizzato da uno strumento automatico per capire che questi due metodi dovrebbero essere raggruppati.

No, non avrà un impatto positivo nel tipo di classe che ho sviluppato o ho visto. Non riesco a pensare a nessun criterio che possa essere usato per raggruppare elementi di classe. L'assunzione da parte dello strumento sarà per lo più cattiva ipotesi.

Molte persone si organizzano spazialmente. Se l'IDE si sta muovendo su di te per far rispettare l'ordine alfabetico dei nomi dei membri, sarà sconcertante per molte persone. Inoltre, molti IDE forniscono accesso diretto ai membri di una classe attraverso un elenco a discesa, che viene ordinato alfabeticamente. Questo dovrebbe essere sufficiente per aiutare le persone che hanno bisogno di cercare un membro della classe.

Uso un modello che crea ciò che potresti chiamare "commenti strutturati" quando avvio un file, questo fornisce una sezione (analoga alle C # #regioni) per ogni classificazione del membro, quindi la ripartizione è come

internal members
  internal static members
  internal constant members
private members
  //etc
protected members
  //etc
public members
  //etc

quindi ripeti sopra con le proprietà

quindi i costruttori

quindi ripeti sopra con

commands:pub,prt,pvt (fns that return void)
event handlers
functions:pub,prt,pvt

fine della classe

Questo ti costringe a pensare e ricordare il ruolo che un membro ha, prima e dopo la sua creazione. A mano a mano che lo sviluppo procede, in genere metto nuove funzioni nella parte inferiore della sezione appropriata fino alla loro maturazione, quindi li migro in una posizione nella sezione che è dipendente o funzionalmente basata.

Una volta installato, crea dei macro in modo da poter saltare rapidamente alla fine di una sezione, io uso un menu popup -

interno, pubblico, protetto, privato  | [Statico, const]    | Membri, proprietà, ctors, comandi, funzioni

quindi le sequenze di tasti sono alt-q, (popup), 1,3,2 - per portarmi alle proprietà const interne

(mi dispiace per il gergo, una proprietà const è semplicemente una senza setter)

Per aggiungere a ciò, creo una macro di espansione che aprirà una finestra di dialogo che richiede nome, parametri e retval, quindi crea lo stub in base alla sezione in cui ci si trova.

Ho scoperto che questo tipo di raggruppamento dei limiti funziona meglio, rispetto ai cluster di membri o ad altri schemi - ti costringe a pensare all'architettura.

Ecco un frammento di ciò che sembra nella vita reale

//#+, public    members
  //;
  //#+*, public static     members
    // ReSharper disable UnaccessedField.Local
    // ReSharper disable InconsistentNaming
     /// <summary>
     /// Public Static Members
     /// </summary>
    private static object __UtilsWin32_public_static_members;
    // ReSharper restore InconsistentNaming
    // ReSharper restore UnaccessedField.Local
    #region "public_static_members"
    // Z_DOT typedef EnumWindowsProc(int hwnd_, int lparam_):bool ::UtilsWin32::UtilsCL:UtilsWin32.cs  z.1711900400436177.2009.05.18.07.08.11|+*,
       /// <summary>
       /// Delegate for EnumWindowsProc
       /// </summary>
       /// <param name="hwnd_">The window</param>
       /// <param name="lparam_">The lparam</param>
       /// <returns><c>true</c> to keep enumerating</returns>
      public delegate bool EnumWindowsProc(int hwnd_, int lparam_);
    // Z_DOT typedef EnumWindowsProcIntPtrIntPtr(IntPtr hwnd_, IntPtr lparam_):int ::UtilsWin32::UtilsCL:UtilsWin32.cs  z.3908448500234277.2011.06.16.12.14.08|+*,
       /// <summary>
       /// Delegate for EnumWindowsProcIntPtrIntPtr
       /// </summary>
       /// <param name="hwnd_">The window</param>
       /// <param name="lparam_">The lparam</param>
       /// <returns><c>true</c> to keep enumerating</returns>
      public delegate int EnumWindowsProcIntPtrIntPtr(IntPtr hwnd_, IntPtr lparam_);
    //;
    #endregion
    //#+*@, public static const members
      //;
  //#+@, public const     members
    //;
  //;
//#%, protected    members
  //;
  //#%*, protected static     members
    //;
    //#%*@, protected static const members
      //;
  //#%@, protected const     members
    //;
  //;

//; è il punto macro di espansione sopra menzionato.