Perché usare System.out.println () è così male? [chiuso]

Naturalmente, è molto utile utilizzare un framework di registrazione per i messaggi di errore o gli avvisi. Ma a volte uso System.out.println () se voglio provare qualcosa di nuovo in breve tempo.

È davvero così male usare System.out.println () per alcuni test rapidi?

Come rivelato nei commenti, la vera domanda che viene posta è: Perché gli strumenti di analisi del codice statico indicano gli usi di System.out.println?

Il motivo è che l'invio di messaggi a stdout è generalmente inappropriato in un ambiente di produzione. Se stai codificando una libreria, la libreria dovrebbe restituire informazioni al chiamante, non stampare su stdout. Se stai codificando un'app GUI, le informazioni dovrebbero essere presentate all'utente, non a dove stdout sembra puntare (che potrebbe non essere da nessuna parte). Se stai codificando un server (o qualcosa che viene eseguito in un contenitore sul lato server), dovresti utilizzare qualsiasi funzione di registrazione fornita dal framework. E così via.

Ma se stai usando println per il debug o lo sviluppo, o stai scrivendo un programma e legge stdin e scrive su stdout, println va benissimo. Non c'è niente di sbagliato in questo tipo di casi.

Tutto stdoutè bufferizzato, quindi è possibile che il programma si arresti in modo anomalo dopo aver chiamato println(), ma prima che raggiunga lo schermo.

Detto questo, questo scenario è davvero improbabile. Vai avanti e usalo, ma mantieni quel limite minore nella parte posteriore della tua mente.

System.outè solo un incartato BufferedOutputStream. Questo è probabilmente simile a qualsiasi framework di registrazione che utilizzerai, i framework forniscono solo più funzionalità sotto forma di configurazione e destinazione dell'output del log

È un male se stai lavorando su un programma non banale e tu

• Stanno usando System.out come stampella anziché come test unitario automatizzato (JUnit)
• Trascorrere molto tempo a creare e cancellare o commentare / annullare il commento delle istruzioni System.out

Ci sono alcune avvertenze sull'uso System.out, anche nel codice usa e getta.

Un grosso problema è che di solito è lento . Ad esempio, se stai cercando di avere un'idea approssimativa della velocità di alcuni codici (nota che i microbenchmark sono difficili ), quindi l'aggiunta di un singolo System.out.println()ovunque può davvero rovinare i tuoi tempi (perché è sincronizzato e spesso attende che l'output effettivo sia essere visibile all'utente prima di tornare).

A parte questo, non me ne preoccuperei troppo nel codice usa e getta. Se si intende impegnarlo (sia come codice di produzione o come codice di prova), è necessario eliminarlo e sostituirlo con una chiamata di registrazione del propper (sì, anche nel codice di prova).

Come spesso accade, la risposta è "dipende". Se l'applicazione dispone già di un framework di registrazione, è possibile utilizzarlo. Non può essere meno capace di println(), e potresti trarre vantaggio da altre funzionalità che fornisce: impilare tracce, contesto extra, migliore formattazione e così via. Esiste inoltre la chiara possibilità che i framework di registrazione offrano un migliore recupero degli errori, garantendo che i log vengano scritti correttamente anche in caso di errore irreversibile.

Quindi la domanda diventa quando aggiungere un sistema di registrazione in primo luogo. Questa è una chiamata di giudizio: non vuoi aggiungerla troppo presto, solo per scoprire che non ne hai davvero bisogno. Inoltre, non vuoi aggiungerlo troppo tardi e fare un lavoro eccessivo convertendolo dalla tua soluzione ad hoc.

Se scopri che stai effettuando molti accessi println(), allora la tua base di codice sta cercando di dirti che sta soffrendo di problemi. A quel punto, vale la pena investire nella registrazione adeguata.

Ho spesso il problema che System.out.print utilizza la tabella codici "predefinita di sistema", che spesso è UTF-8 su Linux, ma alcune cose MS saltate su Windows.

Ciò può portare a caratteri unicode che sono o non sono stampati correttamente sullo schermo, a seconda di dove viene eseguito il programma.

Preferisco quindi un PrintWriter personalizzato rispetto a System.out

Non è affatto male. L'idea potrebbe derivare dal fatto che è molto semplice e non sofisticato come l'utilizzo di un framework di registrazione dedicato nell'applicazione.

Tuttavia, questo non vuol dire che si tratta di un approccio non valido. L'ho usato molte volte per controllare il flusso dell'applicazione dopo alcuni dirottamenti di programmazione voodoo di magia nera .

Non c'è niente di sbagliato nell'usarlo, ti aiuta a capire "che diavolo sta succedendo".

Ma se i tuoi colleghi / altri sviluppatori / strumenti ti stanno ridicolizzando, puoi sempre usare Logger o iniziare i test Junit !

Il problema più grande con l'occasionale System.out.println, a mio modo di vedere, è che si tratta di un "cattivo odore di abitudine (tm)". Se ti ritrovi a fare questo, allora probabilmente potresti migliorare la tua efficacia diventando più comodo usando il tuo debugger preferito.

Anche con un debugger, sai per certo che un breakpoint non scivolerà nel tuo codice di produzione, mentre un System.out.println potrebbe farlo.

In una nota a margine, se in realtà stai solo facendo un test rapido e persisti nel non usare un debugger, penso che System.out.println sia meglio dell'uso di un framework di registrazione, poiché se lasci accidentalmente un'istruzione log.debug quando fatto, è più difficile sradicare.

Costruire un'intera strategia di test per echeggiare il contenuto dello stato interno non è la mossa più intelligente ma per test rapidi e sporchi di codice in sviluppo la stampa dispari qui e lì non farà male finché ti ricordi di rimuoverli!

Il pericolo di dimenticare di rimuoverli è probabilmente il motivo per cui è sconsigliato.