Interruzione di riga prima / dopo operatore [chiuso]

Lo lascerei su una riga e penso piuttosto alla leggibilità in termini di nomi di variabili (e funzioni) che rivelano l'intenzione.

Una volta che è diventato complicato, è tempo di refactor :

• rinomina vars
• introduce nuove vars / funzioni

Esempio

subtotal = price * (100 + tax_ratio) / 100'

vs.

tax = price * tax_ratio / 100
subtotal = price + tax

Posso immaginare che la leggibilità sia un argomento

result = longidentifier +
   short -
   alittlelonger -
   c;

vs

result = longidentifier
   + short
   - alittlelonger
   - c;

Nel secondo esempio gli operatori sono ben allineati e puoi facilmente vedere con quale segno la variabile entra nell'equazione. Penso che questo abbia un senso anche per gli operatori binari, ma con il rinforzo ecc., Dovresti solo fare ciò che è più chiaro.

Normalmente seguo le linee guida di stile più comunemente utilizzate o alcuni strumenti standard di codifica. Il vantaggio dell'uso di uno stile di uso comune porta benefici quando leggi il codice di altre persone o sei coinvolto in un progetto open source in cui sono state impostate le linee guida di stile.

Gli stili più comuni che ho visto sono il secondo stile nella domanda. Vedi sotto per la loro lista:

Guida allo stile di Google :

When a line is broken at a non-assignment operator the break comes before the symbol.

Convenzione Sun Coding :

Break before an operator

Controllo a capo dell'operatore Checkstyle 's valore predefinito è nl:

The operator must be on a new line

Nel codice tendo a mettere la pausa dopo l'operatore:

foo = some_long_expression() +
      some_other_long_expression();

Qui quell'operatore ciondolante alla fine di una riga è un grande indizio per il lettore che il codice continua. Nelle lingue che non hanno terminatori di istruzioni, quell'operatore ciondolante può servire da indizio sufficiente al compilatore / interprete che il codice continua (altrimenti dovrei usare un brutto costrutto di linee di continuazione).

Quando si documenta quell'espressione (se ha bisogno di documentazione), tendo a mettere l'interruzione davanti all'operatore.

Finché rimani coerente, sappi che in entrambi i casi non c'è alcun vantaggio reale. Questo è particolarmente importante quando si considerano l'unione di codice e lo spazio bianco.

Per lunghe equazioni aritmetiche, di solito faccio una delle due cose.

lascia tutto su un'unica riga:

foo = bar + baz - fizz + buzz + alpha - beta;

Solitamente lo faccio per le equazioni contenenti solo addizioni e sottrazioni, trovo molto facile fare un errore di battitura con moltiplicazione e divisione che può compromettere seriamente la portata dell'operatore.

il secondo formato che utilizzo sono gli operatori progressivi:

foo = bar;
foo += baz;
foo -= fizz;
foo += buzz;
foo /= alpha - beta;
foo *= spiff;

Non vedo alcun motivo per abbreviarlo su una singola riga, a meno che non si possa dimostrare che migliora le prestazioni in modo evidente. Inoltre, non c'è alcuna ambiguità su cosa sta succedendo dove, e c'è meno possibilità di collocare erroneamente una parentesi per gli operatori / e * .

Credo che la linea debba iniziare con il simbolo più alto nell'albero di analisi dell'istruzione che si desidera interrompere. Evidenzia l'operatore che è più importante nell'espressione. È lo stesso motivo per cui metti un altro all'inizio di una linea e non alla fine della riga precedente.

Nell'esempio seguente, eseguendo la scansione del margine sinistro, viene visualizzata la struttura dell'istruzione come OR di 3 espressioni.

if (ch>='A' && ch<='Z'
    || ch>='a' && ch<='z'
    || ch>='0' && ch<='9')
{...}

Di seguito, || gli operatori sono meno evidenziati. È meno ovvio che sia un || di espressioni. Soprattutto se le linee erano lunghezze diverse.

if (ch>='A' && ch<='Z' ||
    ch>='a' && ch<='z' ||
    ch>='0' && ch<='9')
{...}

E solo per riferimento, questo è molto sbagliato. || gli operatori non sono evidenziati affatto.

if ( ch>='A' && ch<='Z' || ch>='a'
     && ch<='z' || ch>='0' && ch<='9')
{...}

Mi piace persino mettere le virgole all'inizio della riga, anche se raramente lo vedo. Mi astengo dal farlo su codice condiviso.

var note:Object =
    { key: key
    , type: 'P'
    , text: someLongProcedureCallGettingTheUserInitials()
       + ": " + getTheTextThatWasTyped()
    };

Posizionare il carattere di concatenazione (o qualsiasi operatore) all'inizio della riga migliora la leggibilità. Analizziamo il codice concentrandoci sull'inizio di ogni riga. Quando una linea inizia con un operatore, il lettore può dire che la linea è una continuazione dell'istruzione precedente mediante la scansione di quel carattere.

Le espressioni matematiche lunghe sono sempre composte in modo che ogni nuova riga inizi con un operatore. Non c'è motivo per cui il codice non debba seguire questa convenzione.

Lascia l'espressione su una riga e se diventa troppo lunga, suddividila in espressioni più piccole:

days = ((year * months_per_year) + month) * days_per_month + day

diventa:

months = year * months_per_year + month
days = months * days_per_month + day

Se ciò non è possibile, trovo che sia più leggibile interromperlo prima dell'operatore, e l'operatore deve iniziare direttamente al di sotto del compito precedente (metterlo sotto la variabile mi fa pensare e al più tardi, il che è fastidioso dato che l'obiettivo è rendere le cose più facili da leggere):

random = years * months_per_year 
         + month * days_per_month 
         + day * hours_per_day 
         + hour * minutes_per_hour 
         + minute * seconds_per_minute 
         + second