2012-05-25 13 views
16

Ho un metodo che voglio formattato in questo modo:Come si formatta in modo che i parametri del metodo siano impilati verticalmente, uno per riga?

public static IQueryable<ThingRequest> GetThings(this EntityContext one 
               , int? two = null 
               , int? three = null 
               , int? four = null 
               , int? five = null 
               , String six = null 
               , IEnumerable<String> seven = null) { 

In sostanza, se la definizione del metodo sta per superare la lunghezza della linea linea, mi piacerebbe che ci sia un parametro per riga. Non sono troppo preoccupato per le virgole (se appaiono alla fine di ogni riga, va bene).

Ma R # formati come questo, invece:

public static IQueryable<ThingRequest> GetThings(this EntityContext one, int? two = null, int? three = null, int? four = null, int? five = null, 
                String six = null, IEnumerable<String> seven = null) { 

... Quindi, le linee li, ma ci sono diversi parametri per riga ed è solo difficile scegliere uno qualsiasi dei parametri.

Per inciso, quando chiama i metodi, impila gli argomenti uno per riga se la lunghezza massima della linea è superiore (anche se, in tal caso, preferirei quasi che non lo facesse).

Sono entrato nelle opzioni R # e ho esplorato la vasta gamma di caselle di controllo disponibili, ma non vedo come migliorare la mia situazione. Idee?

+5

Sarei più preoccupato di accettare molti argomenti. – CaffGeek

+5

@CaffGeek Senza alcun contesto, penso che saltare sulla quantità di parametri sia fuori luogo. – ErikE

risposta

16

Prova a cambiare l'opzione da questo percorso:

ReSharper | Options -> 
Code Editing | C# | Formatting style | Line breaks and Wrapping -> 
Line wrapping | Wrap formal parameters 

a CHOP sempre. Non so se è possibile inserire la virgola nel modo desiderato, ma almeno ci sarebbe un parametro per riga. In bocca al lupo!

1

Se si riscontrano problemi nel selezionare "qualsiasi parametro", è necessario prendere seriamente in considerazione la possibilità di modificare la modalità di progettazione di questo metodo.

Uncle Bob Martin ("Codice pulito") consiglia di avere 2-3 parametri max. Se si utilizza più di questo, è probabile che non si possa avere il design più pulito possibile, e dovrebbe essere un suggerimento mentale per rivisitare il motivo per cui si desidera progettarlo in questo modo.

Inoltre, mi rendo conto che questa non è una risposta diretta alla tua domanda, ma potrebbe essere una risposta che fa apparire la tua domanda originale (se decidi di voler ridurre il numero di parametri). Tuttavia, è il tuo codice, quindi in definitiva dipende da ciò che preferisci.

3

Perché non avvolgerli in un oggetto e passare l'oggetto. Crea una classe! E quindi stai passando solo un parametro.

public class MyParam 
{ 
    public EntityContext one { get; set; } 
    public Nullable<int> two { get; set; } 
    ..... 
} 

public static IQueryable<ThingRequest> GetThings(MyParam TheParameters) {...} 

In questo modo, in seguito, è anche possibile aggiungere un metodo che convalida i parametri, ad esempio.

E se si voleva davvero essere intelligenti, è possibile aggiungere il metodo GetThings a questa classe e ora si sta parlando di OOP!

+0

@ Sam.Rueby: au contraire! Penso che il vero problema dell'OP non sia che i parametri non rientrano in una riga; il vero problema è il modo in cui non sta incapsulando questi e non usando i principi OOP. E questo è il motivo per cui sta sbattendo il problema "I miei parametri non si adattano in una sola riga". Quindi penso che la mia risposta risolverà il suo problema. Sentiti libero di aggiungere anche la tua risposta. – frenchie

+0

Capisco. Non penso proprio che sia realistico creare una nuova classe ogni volta che viene creato un nuovo metodo che richiede più di alcuni parametri: questo finirà per essere davvero disordinato.Inoltre, non penso che sia realistico per le persone suggerire che un metodo dovrebbe * non * essere creato che richiede ~ 7 parametri. Sì, 20 è probabilmente in terra povera di design. Ma 7 è più che legittimo, specialmente se segue più principi di programmazione funzionale invece di OOP. Sono sicuro che sa che potrebbe creare una classe per incapsulare i parametri; la vera domanda qui riguarda R # e le sue abilità. –

+2

E quanti argomenti ha il costruttore per questa nuova classe? Basta chiedere? –

Problemi correlati