I progetti casuali su Github omettono il controllo degli errori, la registrazione, ecc., per motivi di chiarezza?

Question

I progetti casuali su Github omettono il controllo degli errori, la registrazione, ecc., per motivi di chiarezza?

#1 da (11 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)

3

Ho appena iniziato a utilizzare GitHub per socializzare alcuni progetti per semplici chat e app peer-to-peer. Per quanto riguarda la codifica, è consuetudine omettere la gestione delle eccezioni, il controllo degli errori, la registrazione, ecc., Per promuovere un codice di facile comprensione e 'pulito', se tali aggiunte non sono completamente necessarie per eseguire realmente il codice? / p>

Ad esempio, ecco due esempi estremi:

   if( msg != null){
      NodeEvent event = NodeEvent.valueOf(msg.getAction());
      switch (event) { 
        case NODE_CONNECTING:
          if( nodeName.isInvalid())
             Utils.log("Invalid node name, ignoring...");
          else{
             String existingNodeAddress = _nodeNameAddressMap.get(nodeName);
             if( existingNodeAddress != null)
                Utils.log("Node address for '" + nodeName + "' updated");
             else
                Utils.log("New node '" + nodeName + "' connected"); 

             _nodeNameAddressMap.put(nodeName, nodeAddress);
          }
    }

Ecco lo stesso snippet meno il fluff, sebbene questa versione possa facilmente bloccarsi se viene alimentata con dati errati, ma altrimenti verrà compilata e funzionerà correttamente:

   NodeEvent event = NodeEvent.valueOf(msg.getAction());
   switch (event) {   
     case NODE_CONNECTING:
        _nodeNameAddressMap.put(nodeName, nodeAddress);

La versione pulita è più facile da leggere, ovviamente, ma è fragile. La versione dettagliata è più sicura, sembra solo ingombra.

Sono solo curioso di sapere se è più efficace per un progetto sociale scegliere l'aspetto più pulito a scapito della fragilità, consentendo a chi spinge il progetto a riempire gli spazi vuoti. Una rapida panoramica dei progetti di github ed è chiaro che la maggior parte cerca il look pulito.

clean-code java github

posta raffian 25.09.2013 - 06:21

fonte

4 risposte

Leggi altre domande sui tag clean-code java github

Sviluppo mobile multipiattaforma? [chiuso] Quando un codice è considerato stretto e in che modo aumenta l'efficienza del codice?

score 11 · Answer 1

Penso che tu stia confondendo a scrivere libri che parlano di codice e scrittura di codice che deve essere eseguito da un vero computer.

"per brevità" è qualcosa che un autore di libri dice quando vuole illustrare un punto e la ragione per cui l'autore dice che è così che quando leggi quel libro, ti concentri sul suo punto previsto, ma capisci anche che questo il codice è incompleto e NON DEVE essere preso come esempio diretto di come si dovrebbe scrivere codice.

Quando avvio un progetto, quasi la prima cosa che faccio è definire lo schema di registrazione standard e accertarsi che ci sia una convenzione in atto per la gestione degli errori. Non lo sto facendo "per essere completo" ma perché quando scrivo codice, introdurrò bug e anche se non lo faccio, le cose andranno male. Personalmente, preferirei trascorrere 4-8 ore in anticipo assicurandomi di avere un file di registro magari anche con la possibilità di cambiare il livello di registrazione, piuttosto che scrivere un intero gruppo di codice solo per incappare in un bug e rendermi conto che tutto ciò che ho scritto è un scatola nera e non ho idea di dove si stia fallendo o anche da dove cominciare a cercare.

E se non si ha la gestione degli errori, significa invece di identificare le tracce dello stack in cui si è verificato l'errore / arresto anomalo e di chiamare effettivamente i posti che non sono riusciti (ovvero quella chiamata di sistema che non ha restituito una risorsa), la tua app vai solo per crash / fail altrove, potenzialmente mascherando il vero problema nel processo

La gestione degli errori / della registrazione è lì solo per aiutarti ad andare più veloce nel lungo periodo. Ma alla fine, dipende completamente da te. Se ritieni di poter realizzare un progetto più velocemente e soddisfare qualche tipo di standard di qualità (ad esempio "la tua app effettivamente utilizzabile" sarebbe uno standard) senza errori di gestione, quindi esegui la procedura. La registrazione / gestione degli errori sono solo strumenti che ti aiutano ad arrivare più velocemente con meno sforzo, ma, proprio come con qualsiasi strumento, decidi se ne vale la pena. Ma dalla mia esperienza, in quasi tutti i progetti che ho mai fatto, lo erano assolutamente.

score 2 · Answer 2

Su Github, molte persone stanno pubblicizzando il loro progetto open source, piuttosto che archiviarlo e condividerlo. Ho notato solo ieri che il caso d'uso consigliato per una delle librerie di rete che utilizzo quotidianamente non controlla in realtà se il server esiste prima di presupporre che la connessione sia riuscita.

Le persone vogliono che il loro esempio appaia incredibilmente semplice, in modo che tu possa prendere in mano il loro grimorio e fare qualcosa con esso. Le condizioni di errore sono un ripensamento, perché se devi guardare un esempio del mondo reale (che potrebbe essere parecchie volte più lungo) rispetto all'esempio fornito, l'esempio fornito apparirà sempre più carino.

CPAN ha sempre adottato un approccio diverso: in genere è chiaro dai documenti quale sia l'utilizzo corretto del modulo, incluso qualsiasi controllo degli errori richiesto.

Sembri più come CPAN, e meno come i quadri reattivi, espressivi, agili, dinamici e sinergici che trovi su Github.

score 1 · Answer 3

Se si tratta di codice destinato a essere eseguito in ambienti live (effettivamente utilizzato nei programmi reali), includere tutti il controllo e la registrazione degli errori necessari. Se è destinato a fini didattici solo , puoi tranquillamente lasciarlo fuori per chiarezza. Ma assicurati di contrassegnarlo come tale. Potresti anche voler includere tale codice di apprendimento solo nella documentazione, quindi non c'è confusione.

Tieni presente, se stai utilizzando questo codice come una vetrina per potenziali datori di lavoro, se lo eseguono e ha tonnellate di eccezioni non gestite, come ti faranno apparire?

score 0 · Answer 4

Ecco la cosa con i controlli di errore come le stampe che hai inserito; non sono davvero tanto necessari se stai usando un buon controllo del codice sorgente (e se stai usando GitHub, stai usando Git, quindi lo sei). Impara ad usarlo bene e non dovrai farti domande del genere. Dice anche che potresti non utilizzare i test automatici nel miglior modo possibile.

Se leggo un codice come questo, potrei fare alcune ipotesi come "Questa persona è una specie di dilettante" o "Questa persona non sa come utilizzare il controllo del codice molto bene". Potrei anche pensare "Questo codice è stato esaminato abbastanza bene" o "Questa persona ha un buon pensiero". Come penso che dipenda dalla situazione, ma lasciare nelle stampe significa che potrei pensare al precedente modo più che al secondo .

Il codice che pubblichi dice qualcosa su di te come programmatore. Tienilo a mente.