Perché molti codici sono così? - pagina 3

Nuovo commento
 
RaptorUK:

Ma questo non significa che se stanno chiedendo aiuto con la sintassi o la logica il codice non sarà " . . essere sintatticamente e logicamente corretto;" ?

Sì, hai ragione. Ma nel contesto della discussione sugli stili/pratiche di codifica più (o meno) efficaci, l'aspetto più importante è che il codice sia sintatticamente e logicamente corretto, indipendentemente dallo stile di codifica utilizzato. Credo che un altro modo di dire sia che lo stile deve cedere il passo al codice sintatticamente e logicamente corretto - la questione principale non è se il codice è bello e facilmente leggibile, ma, piuttosto, se è sintatticamente e logicamente corretto per eseguire il compito per cui è scritto. :)

Sono anche d'accordo sui // commenti. Non si possono mai avere troppi // commenti, sia per rinfrescare la mente del programmatore originale per quanto riguarda i particolari delle varie parti del codice che per assistere/aiutare la comprensione del codice da parte di altri dopo il completamento/implementazione.

 
Thirteen:

Sì, avete ragione. Ma nel contesto della discussione sugli stili/pratiche di codifica più (o meno) efficaci, l'aspetto più importante è che il codice sia sintatticamente e logicamente corretto, indipendentemente dallo stile di codifica usato. Credo che un altro modo di dire sia che lo stile deve cedere il passo al codice sintatticamente e logicamente corretto - la questione principale non è se il codice è bello e facilmente leggibile, ma, piuttosto, se è sintatticamente e logicamente corretto per eseguire il compito per cui è scritto. :)

Ah OK, ho capito cosa stai dicendo... il codice ben presentato non serve a nulla se non funziona... ma forse è più facile da correggere?
 
RaptorUK:
Ah OK, ho capito cosa vuoi dire... il codice ben presentato non serve a niente se non funziona... ma forse è più facile da correggere?
Corretto. In altre parole, gli stili/pratiche di codifica e la presentazione, che sono in gran parte la scelta del programmatore, sono un mezzo per un fine (il fine è un codice sintatticamente e logicamente corretto). :) Quando il codice può essere facilmente letto e compreso dal programmatore (e successivamente da altri che non hanno scritto il codice), è molto più facile individuare e correggere gli errori sintattici e/o logici.
 

Penso che la maggior parte degli stili di codifica permetta tanta leggibilità quanta ne vuole o ha bisogno il codificatore, io chiudo il mio codice quando è finito e funziona, ma è facile riaprirlo con alcuni spazi di linea se ho bisogno di condividerlo o discuterlo. Penso che un formato di codifica dovrebbe supportare una facile identificazione di una parentesi mancante, e una facile identificazione delle coppie if else quando c'è un complesso albero if else con più rami. Non ho mai adottato lo stile K&R quindi mi piacerebbe vedere come lo fanno i codificatori in stile K&R.

 
SDC:

Chiudo il mio codice quando è finito e funziona, ma è facile riaprirlo con alcuni spazi di linea se ho bisogno di condividerlo o discuterlo.

Perché chiuderlo del tutto? Davvero non capisco il senso del codice schiacciato. Se hai bisogno di aprirlo per condividerlo/discuterlo cosa implica?

SDC:

Penso che un formato di codifica dovrebbe supportare una facile identificazione di una parentesi mancante, e una facile identificazione delle coppie if else quando c'è un complesso albero if else con più rami. Non ho mai adottato lo stile K&R, quindi mi piacerebbe vedere come lo fanno i codificatori dello stile K&R.

Per lo stile K&R, la parentesi graffa inferiore si allinea con la condizione corrispondente. Personalmente uso

1. Rientro coerente

2. Per le clausole a dichiarazione singola, sia le parentesi graffe che i rientri, oppure farle seguire alla condizione senza parentesi graffe, cioè.

if (flag) {
   i++;
}

OR

if (flag) i++;

3. Usare un editor di programmazione decente che faccia corrispondere le parentesi graffe.

Le parentesi corrispondenti non sono un problema - la maggior parte del kernel linux è scritto in questo stile, ed è lo standard Java. Anche se posso vedere l'attrazione dello stile Allman come, con lo stile K&R, spesso inserirei una linea bianca extra dopo la condizione per liberare il codice. Hmm potrei essere convertito :)

 
ydrol:

Perché chiuderlo del tutto? Davvero non capisco il senso del codice schiacciato. Se avete bisogno di aprirlo per condividere/discutere cosa implica?

Per lo stile K&R, il tutore inferiore si allinea con la condizione corrispondente. Personalmente uso

1. Indentazione coerente

2. Per le clausole a dichiarazione singola, sia le parentesi graffe che i rientri, oppure farle seguire alla condizione senza parentesi graffe, cioè.

3. Usare un editor di programmazione decente che faccia corrispondere le parentesi graffe.

Le parentesi corrispondenti non sono un problema - la maggior parte del kernel linux è scritto in questo stile, ed è lo standard Java. Anche se posso vedere l'attrazione dello stile Allman come, con lo stile K&R, spesso inserirei una linea bianca extra dopo la condizione per liberare il codice. Hmm potrei essere convertito :)

Io lo chiudo solo per occupare meno spazio sullo schermo. Mi piace vedere tutto il codice allo stesso tempo che può stare sullo schermo. Non ho bisogno di un brace matcher, lo formatto in modo che se metto un cursore dietro un brace e lo faccio correre verticalmente su per le linee con il tasto freccia, quando tocca un altro brace quello è la sua coppia. se lo metto dietro un else e faccio la stessa cosa, quando tocca un if quella è la coppia if else.

In questa sezione di codice è facile vedere che il terzo else accoppia il primo if, il secondo else accoppia il secondo if il primo else accoppia il terzo if perché le parentesi graffe dietro ogni else si allineano verticalmente dietro la corrispondente parentesi if. Allo stesso modo è facile vedere quali if non hanno un else perché ogni if si allinea verticalmente con la sua corrispondente parentesi di chiusura nel gruppo dietro l'else. Non sto suggerendo a tutti gli altri di formattare il codice in questo modo solo perché a me piace, ma per me è compatto e logico.

      if(downtrend)
      {if(High[i] < LineDownBuffer[i+1])
       {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
        }else
        {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1])
         {LineDownBuffer[i] = DeMarkerHighBuffer[i];
       }}}else
       {if(High[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
         LineUpBuffer[i] = DeMarkerLowBuffer[i];
         downtrend = false;
         uptrend = true;
      }}}else
 
SDC: Penso che la maggior parte degli stili di codifica permetta la leggibilità che il codificatore vuole o ha bisogno, io chiudo il mio codice quando è finito e funziona, ma è facile riaprirlo con alcuni spazi di linea se ho bisogno di condividerlo o discuterne. Penso che un formato di codifica dovrebbe supportare una facile identificazione di una parentesi mancante, e una facile identificazione delle coppie if else quando c'è un complesso albero if else con più rami. Non ho mai adottato lo stile K&R quindi mi piacerebbe vedere come lo fanno i codificatori in stile K&R.

Non posso rispondere a questo per tutti i codificatori che usano K&R. Onestamente, più guardo il tuo formato e più mi piace. Se avessi adottato lo stile Allman, potrei sicuramente vedermi usare la tua versione modificata. Le parentesi graffe si allineano l'una sotto l'altra, liberandosi delle parentesi di apertura e di chiusura che occupano un'intera riga. Puoi far scorrere il cursore lungo la i sopra l'if e trovare le parentesi mancanti, senza preoccuparti delle convenzioni sulla dimensione di tabulazione/indentazione, modalità compatta {vedi la maggior parte dei tuoi codici sullo schermo}. Quindi sì, è abbastanza figo, è solo a prima vista, perché non sono abituato, sembrava confuso. E questo è il cuore della questione qui.

A me sembra che molti coder americani adottino lo stile [KnR & Allman], mentre lo stile Whitesmiths sembra popolare tra gli europei. Whitesmith è anche lo stile predefinito per Mt4. Ora non c'è niente di sbagliato in nessuno di questi stili, è solo che quando sto aiutando qualcuno, devo continuare a ricordare a me stesso di ignorare il mio stile K&R e pensare più a Whitesmith. Questo o usare un formattatore di codice.

Perché qualcuno dovrebbe voler scrivere "alberi complessi if else" è al di là di me. Quando qualcuno lascia tutto il White_Space e la formattazione all'interno di un complesso if_nest, sembra che stiano cercando di progettare uno Snake | Spaghetti | ZigZag attraverso la pagina. Il primo if inizia sulla linea 1 e finisce sulla linea 300, circa 150 o %50 di quelle linee sono tenute da parentesi graffe. Invece dei "complessi alberi if else" perché non creare semplicemente una funzione? Poi lasciate che la linea_1 finisca effettivamente sulla linea_1 con if( false ){ return; }.

 

Grazie ubzen Sono contento che a qualcuno piaccia il mio formato lol. Uso spesso gli if else, probabilmente perché quando ho iniziato a programmare qualcuno mi ha detto che gli if else rendono il codice veloce, così ho preso l'abitudine di farlo in quel modo.

 
SDC:

Grazie ubzen Sono contento che a qualcuno piaccia il mio formato lol. Io uso spesso if else, probabilmente perché quando ho iniziato a programmare qualcuno mi ha detto che if else rende il codice veloce, così ho preso l'abitudine di farlo in quel modo.

Non è niente di personale


È in momenti come questo che sarebbe stato bello avere uno standard formale applicato a cui tutti lavorano. . . . allora faremmo tutti la stessa cosa e ci piacerebbe il tuo codice. E prima che tu lo chieda, no, continuerò con il mio stile Whitesmiths . . . almeno so come chiamarlo ora, grazie ubzen

 
Sei il benvenuto SDC e RaptorUK. Il coding è un argomento molto più facile da discutere di Winning_EA. :)
1234
Nuovo commento