Quanto deve / dovrebbe il tuo stile implicare la tua abilità in una lingua? [chiuso]

Le lingue moderne più popolari hanno una sintassi simile (con piccole modifiche qua e là). Ma ogni lingua ha il suo stile unico di essere usato. Questo stile di solito si è sviluppato nel corso di molti anni ed è il risultato di come il linguaggio funziona al di sotto combinato con l'esperienza degli utenti per evitare brutti problemi nella lingua.

Quando la maggior parte degli sviluppatori migrano da una lingua all'altra prendono lo stile della loro lingua preferita con loro e cercano di applicarla alla nuova lingua. Ora questo va bene mentre stai imparando (dato che non hai altri riferimenti da seguire). Non sono bravo a perl, quindi scrivo perl come C ++ (con alcune modifiche (ma riconosco che il mio perl non è buono)). Vedo che gli sviluppatori Java provano e usano C ++ come Java e creano un pasticcio completo del codice (perché non si adatta bene).

Ma a lungo termine questo è un approccio sbagliato. Il linguaggio ha uno stile particolare per una ragione ed è meglio cercare di capire questo e imparare lo stile per quella lingua. Rende la curva di apprendimento più ripida (e si può ricorrere al vecchio stile di tanto in tanto per ottenere risultati), ma a lungo termine sarà sicuramente vantaggioso apprendere lo stile corretto per la lingua.

Motivo per imparare lo stile di lingua corretto:

• Integrazione con il codice esistente meglio
• Evita le insidie del linguaggio che non sono ovvi
• Permetti ad altri utenti di capire facilmente il tuo codice
  • Puoi sempre risolvere il problema ma leggere un codice diverso da quello che ti aspetti è molto più difficile rispetto alla lettura dello stile che ti aspetti.

Does code like that imply to others that I don't have control of the language because I didn't use all the features?

Sì, lo fa. I bravi programmatori Perl conoscono bene Perl e lo usano efficacemente.

Se stai scrivendo cinque righe di Perl in cui si farebbe molto bene, non aspettarti un caloroso benvenuto da parte di un team di programmatori Perl. I team scelgono Perl e lingue simili per fare di più con meno codice. Non è solo una questione di stile, è una questione di tempo e denaro. Ci vuole molto più tempo per leggere e capire:

my @selectedThings
for (my $i = 0; $i <= $#things; ++$i) {
  my $t = $thing[$i]
  if ($t ... ) {
    @selectedThings.push $t
  }
}

a:

my @selectedThings = @things.grep { ... }

La chiamata grep è chiara per un programmatore Perl. L'equivalente multi-linea potrebbe dire qualsiasi cosa e potrebbe facilmente contenere un bug.

C'è un'enorme differenza nel costo di sviluppare e mantenere un'applicazione di 25.000 linee rispetto a un'applicazione di 5.000 linee, anche se fanno esattamente la stessa cosa.

I always use C-style for loops and use map about once in every 10,000 lines of code, so I almost always have to reference it before using it.

Questa è una forma di ciò che Larry Wall chiamava "falsa pigrizia". Ogni volta che è possibile utilizzare la mappa, ma invece scrivere un codice più lungo ma più familiare, si salva qualche secondo una volta. Ma impiegare alcuni minuti per imparare davvero la mappa ti farà risparmiare centinaia di righe di codice e molte ore in futuro.

While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages.

Questo atteggiamento non funziona bene in una squadra. Il team conosce Perl e non ha il tempo di guadare il codice extra perché non è il tuo stile .

1) Come ikegami, trascorro un bel po 'di tempo su SO rispondendo alle domande di Perl e uno dei miei consigli più comuni è "non usare C-style for loops in Perl; usa invece la versione iterating dell'elenco perché è più difficile rovinarlo ". Se scrivi for my $i (1 .. 10) , non c'è modo di ottenere le condizioni al contorno errate, in più è più veloce da scrivere e richiede meno pensieri rispetto all'equivalente in stile C. Se fossi un intervistatore e ti vedessi scrivere for (my $i = 1; $i <= 10; $i++) invece, ti chiederei quanto bene conosci Perl e se stavi scrivendo Perl direttamente o se stavi pensando in C, poi traducendolo in Perl.

Se ti vedessi scrivere for (my $i = 1; $i <= 10; $i++) { $data = $some_array[$i];... } invece di for my $data (@some_array) { ... } , d'altra parte, concludo che chiaramente non conosci Perl molto bene e l'intervista sarebbe abbastanza bene nella mia mente, supponendo che fosse per una posizione Perl con esperienza. (A meno che $i debba essere utilizzato per qualcos'altro oltre all'indicizzazione sequenziale in @some_array , ma anche in questo caso preferirei for (..) a for (;;) .)

Lo stile conta, specialmente con un linguaggio che è come TIMTOWTDI come Perl. Ci sono molti modi per farlo, ma non tutti sono ugualmente buoni (per ogni dato valore di "buono", che varia da situazione a situazione). L'utilizzo di tutte le funzionalità linguistiche non è necessario per un buon stile, ma usare quelle giuste quando sono appropriate ti porterà molto lontano in quella direzione.

2) Per quanto riguarda la risposta concatenata, il tuo codice mi sembra buono in generale. La cosa principale che mi pongo è il prefisso & sulla tua chiamata alla funzione finale. Non ne hai bisogno (a meno che tu non stia scrivendo Perl 4, nel qual caso hai lontano problemi più grandi!) Ed è generalmente scoraggiato in questi giorni perché ha effetti collaterali che non sono immediatamente evidenti . Punti bonus definiti per l'utilizzo di strict , tre-arg open , filehandle lessicali e moduli CPAN, tuttavia.

Sul punto più grande della tua seconda domanda, riscrivo spesso il codice della gente per ripulirlo e mostrare (almeno alcuni elementi di: cerco di abbinarlo al loro apparente livello di abilità) come lo farei. Non è inteso come una minima sull'autore originale; è un tentativo di aiutare e educare oltre la domanda immediata. Di solito è anche abbastanza divertente. Ma, forse la cosa più importante, il semplice fatto è che Perl ha un problema di immagine. Ci sono un sacco di persone là fuori (* cough * Job * cough *) che pensano che "non esiste nulla come un buon stile Perl" e penso che sia importante smentire questa convinzione mostrando Perl ben mantenuto e mantenibile codice quando l'opportunità si presenta.

Non penso che lo stile particolare sia importante in una domanda sul codice dell'intervista, ma è bello vedere che ne hai uno e sei consapevole del perché fai le cose nel modo in cui lo fai.

In base alla tua domanda, sembra che tu non abbia reagito favorevolmente alle critiche. Dici che ti rendi conto che il tuo stile dovrà adattarsi, ma potresti non aver dato quell'impressione. Pensi di essere sulla difensiva? Questo può essere interpretato come non volendo cambiare.

While I can interpret others code using that, it's not my style and that is for reasons involving readability and ease of changing between languages.

Questo mi sembra strano. Trovo molto più difficile passare da due lingue simili a quelle tra due che sono molto diverse. Quando due lingue hanno molto in comune, c'è la tendenza a inserirle entrambe in un modello mentale comune e alla fine devi ricordarti costantemente di tutte le differenze.

Sono sicuro che chiunque usi sia C che C ++ ha lasciato che qualche C ++ si inserisse nel proprio codice C o si fosse dimenticato di sfruttare le utili funzionalità del linguaggio in C ++. Non hai mai quel problema quando passi da, ad esempio, C ++ e Scheme, perché le due lingue non sono simili allo stesso modo.