Strumento di programmazione più sottovalutato [chiuso]

35

Abbiamo molti ottimi strumenti che aiutano molto durante la programmazione, come buoni programmatori editor di testo, IDE, debugger, sistemi di controllo della versione ecc. Alcuni strumenti sono più o meno "indispensabili" per portare a termine il lavoro (es. Compilatori) .

Ci sono ancora strumenti che aiutano molto, ma non ottengono così tanta attenzione, per vari motivi, ad esempio quando sono stati rilasciati, erano in anticipo sui tempi e ora sono più o meno dimenticati.

Quale tipo di strumento di programmazione pensi sia il più sottovalutato? Motiva la tua risposta.

tools developer-tools

— anto
fonte

3

I nostri cervelli? - -

— Trufa

Ok, chi vuole aggiungere la voce Lisp? * ghigno *

— Marco C

70

Un'anatra di gomma. Sì davvero.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Il debug di paperelle di gomma , paperelle di gomma e il test di paperelle di gomma sono termini informali utilizzati nell'ingegneria del software per fare riferimento a un metodo di codice di debug. Il nome è un riferimento a una probabile storia apocrifa in cui un programmatore esperto senza nome avrebbe sempre tenuto un'anatra di gomma dalla sua scrivania e avrebbe eseguito il debug del suo codice costringendosi a spiegarlo, riga per riga, all'anatra.

Per utilizzare questo processo, un programmatore spiega il codice a un oggetto inanimato, come un'anatra di gomma, con l'aspettativa che al raggiungimento di un pezzo di codice errato e cercando di spiegarlo, il programmatore noterà l'errore. Nel descrivere ciò che il codice dovrebbe fare e nell'osservare ciò che effettivamente fa, qualsiasi incongruenza tra questi due diventa evidente ...

— Andiaz
fonte

6

Lo faccio sempre con mio marito. Come tecnico di supporto tecnico con solo una manciata di capacità di programmazione, capisce circa il 60% di ciò che dico ma mi costringe a spiegare il 40% che non capisco. Il numero di occasioni in cui funziona è davvero impressionante.

— Ethel Evans,

1

Tu ridi Avevo davvero un collega con un'anatra di gomma sulla sua scrivania.

— Berin Loritsch,

57

L'ho provato, ma la mia papera di gomma non sembrava concentrarsi sul problema. Dove posso trovare un'anatra di gomma adeguatamente qualificata con un interesse genuino per la programmazione?

— Steve314

3

Per questo uso il mio diario. A volte ho delle discussioni piuttosto lunghe con me stesso. Vorrei poter farmi capire cosa intendo, a volte. Scrivere questo in un diario a volte aiuta molto più tardi, quando mi chiedo a cosa stia pensando l'idiota che ha scritto il codice a cui sto lavorando.

— Lars Wirzenius,

1

@Steve: i ricercatori giapponesi ci stanno lavorando, ma non credo che siano vicini: youtube.com/watch?v=3g-yrjh58ms

— Rei Miyasaka

42

Penna e taccuino.

Funziona senza elettricità.
Portatile.
Doodle on / in quando annoiato nelle riunioni
Memorizza informazioni utili.
Se è scritto, le persone attribuiscono maggiore importanza ad esso.
Altri possono leggerlo e imparare.

— Sparky
fonte

Ai vecchi tempi delle grandi società, agli ingegneri e ai tecnici venivano dati quaderni tecnici vuoti in cui scrivevano tutte le cose che tendiamo a mettere in vari file sui nostri dischi rigidi. Quando i quaderni venivano riempiti, venivano spediti in un deposito sicuro e ignifugo. Se qualcuno avesse bisogno di avere accesso a quelle note, potrebbe controllare i notebook.

— oosterwal,

3

I russi hanno usato una matita.

— Giobbe

@Job Hah, uso ancora una bottiglia di inchiostro! (... Beh, solo per calligrafia, ma comunque. :))

— Mateen Ulhaq

Che dire dei tablet PC?

— Mateen Ulhaq,

1

@Job: ... e vodka!

— Spoike,

38

Gli strumenti diff sembrano essere sottoutilizzati quando si confrontano output di log o dati in file di testo semplici. O forse è solo una nicchia? Mi sembra molto utile e utile per il debug confrontare grandi registri di esecuzioni di programmi e individuare uno o due dettagli che sono cambiati.

Anche gli strumenti di profilazione delle prestazioni sono molto buoni da avere, specialmente quando si raggiunge un collo di bottiglia critico, ma sembra che pochissime persone abbiano familiarità con loro (e ammetto che mi sono laureato in questa categoria).

I buoni strumenti XML sono fondamentali: se lavori con file XML più di una dozzina di linee o schemi multipli. A volte hai bisogno di qualcosa di più della semplice sintassi di base evidenziata da altri editor. Inoltre, quando si lavora con XML, l'apprendimento dell'XSL può essere molto utile. Molte volte vedo cosa si potrebbe fare in una semplice trasformazione XSL fatta in molte righe nel codice dell'applicazione. Anche se per chiarire: io non suggerendo che XML stesso è uno "strumento di programmazione sottovalutato"; Sto suggerendo che il valore di buoni editor XML è sottovalutato, da quello che ho visto.

— FrustratedWithFormsDesigner
fonte

1

++ È assolutamente diffsottovalutato. In materia di profilazione, non sei il solo a pensare che debbano essere utili, ma tu stesso non sai come fare. Controllare questo.

— Mike Dunlavey,

Sì, ho pensato di imparare davvero uno strumento di profilazione, ma non ci sono mai arrivato

— Anto

23

+1 per la profilazione, +1 per gli strumenti diff, -1 per gli strumenti XML. Alcune persone, quando si presentano un problema, pensano "Lo so, userò XML".

<Problem:Worsening>  <Problem:TimeDescription>Now</Problem:TimeDescription>  <Problem:Posessive>they have</Problem:Posessive>  <Problem:Quantity>many, many</Problem:Quantity>  <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>

— Mason Wheeler,

2

@Mason: XML carino.

— Mike Dunlavey,

10

@Mason Wheeler: Non ho suggerisco XML come strumento per risolvere i problemi, ho suggerito buoni strumenti XML - quando si ha a lavorare con XML, assicuratevi di avere un editor / strumento che è molto bravo a farlo. Qualcosa che può eseguire query Xpath, convalida dello schema, trasformazione, confronto valore / struttura (un tipo speciale di strumento diff immagino) ecc ... I semplici editor con l'evidenziazione non riescono a tagliarli quando le cose diventano sporche - spesso rendono le cose peggio (tra l'altro mi piace il tuo codice XML;)).

— FrustratedWithFormsDesigner

37

Espressioni regolari

Sono così utili. Aiutano durante la ricerca di file di registro, l'analisi del testo ecc. Sono estremamente utili.

Trovo strano quante persone che conosco che non le usano mai perché a loro è associata una curva di apprendimento. Molte volte vedo che le persone fanno le cose nel modo più duro (Nota: prima di regex ho fatto le cose nel modo più duro) quando un semplice regex riusciva a farlo rapidamente.

— barrem23
fonte

8

Ricorda che le espressioni regolari non sono un coltellino svizzero anche se sono fantastiche se applicate correttamente.

— Anto

10

Estremamente utile - ma spesso abusato, che porta a codice criptico non mantenibile. Il vecchio detto "ora hai due problemi" ha delle basi nella realtà.

— Steve314

4

RegExes è un coltellino svizzero: uno strumento adeguato per molti lavori veloci, anche se probabilmente non lo strumento giusto per costruire un'intera casa.

— JasonTrue,

4

Hmm, per qualche motivo ho sempre avuto l'impressione che regex fosse lungi dall'essere sottovalutato. Troppo spesso vedo persone che cercano una regex in cui basterebbe un semplice split / for-loop o quando le regex non sono semplicemente la risposta (ad esempio, l'analisi di xml / html).

— MAK,

Ho visto entrambi i fenomeni: Regex? Quella roba è illeggibile / lenta / inserisci peggiorativo qui e "Qual è il modo migliore per analizzare (inserire grammatica completamente non regolare) con una regex?"

— JasonTrue,

24

I tuoi compagni di squadra. Quando sei fuori per qualche idea hot-shot e dimentichi di incorporare la tua squadra, non sentirai mai le loro preoccupazioni o idee sul perché non funzionerà o sul perché potrebbe essere ancora migliore.

Dico questo, perché è facile pensare che la programmazione sia una cosa antisociale che le persone fanno negli angoli con le loro idee geniali. Le persone che pensano che ciò sottovaluti il valore delle squadre e dei loro compagni nel contribuire a far affondare / nuotare idee / progetti.

— Doug T.
fonte

I buoni compagni di squadra non potranno mai essere sopravvalutati. La maggior parte dei software e hardware può farlo.

— Tipo anonimo

19

Google. Esistono pochissimi problemi che non sono già stati risolti e documentati. Una query Google ottimizzata può far risparmiare a tutti molto tempo.

— Adam Crossland
fonte

13

Un buon strumento ma non sono sicuro che lo definirei sottovalutato, almeno non più (forse avrei concordato 9 o 10 anni fa).

— FrustratedWithFormsDesigner

12

Mi dispiace, ma Google ha sottovalutato? Per lo meno Google è sopravvalutato :)

— est

2

Lo so, lo so! Ma la mia logica per dire che è sottovalutata è quella con cui sospetto che sarete d'accordo: almeno il 75% delle domande poste su StackOverflow è facilmente rispondibile con Google, sì? Chiaramente, è in qualche modo sottovalutato se molte persone non lo usano. Se la mia logica è difettosa, eliminerò la mia risposta.

— Adam Crossland,

3

@Adam Crossland: il 75% è gentile. Penso che sia più alto di così.

— S.Lott

1

@adam @ s.lott quindi immagino che il punto sia che Google non sia usato correttamente. Con quello sono d'accordo. È possibile rispondere a tante domande (non è necessario che vengano poste) se le persone sapessero come Google correttamente. Saluti.

— est

16

Di gran lunga lo strumento più sottovalutato per trovare "colli di bottiglia" è Ctrl+ Co il pulsante "Pausa", in un debugger.

Controlla l'ultimo paragrafo di questo post , e questo post , e questo post , per cominciare.

Quante volte vedo / sento parlare di persone che dicono "Il programma è troppo lento! Cosa posso fare al riguardo? Ho provato un profiler (se lo hanno fatto), ma non capisco cosa dice. Qualcuno ha qualche idea? Aiuto! " Bene, le ipotesi sono proprio questo. Quello che ho sempre fatto, e anche altri, è farlo funzionare, interromperlo ed esaminare lo stack di chiamate. Se il problema è davvero grave, bingo , è proprio di fronte a te. Se il problema è solo lieve, lo fai più volte. Tutto ciò che appare su più di un campione, che puoi evitare, è un collo di bottiglia che puoi correggere.

Sì, questa è un'esca negativa, ma funziona.

— Mike Dunlavey
fonte

Non bisogna sottovalutare gli strumenti contundenti. Chiaramente questa non è sempre la risposta giusta, ma può essere. Chiamalo un'approssimazione del primo ordine, per essere raffinato da un vero profiler, se necessario.

— Kristof Provost,

@Kristof: È allettante pensarlo, e ci sono problemi che non può gestire, e ci sono casi in cui i campioni non sono facili da ottenere, ma neanche i profiler possono gestire quei casi, tranne per un certo tipo, come Zoom , e anche allora non sono effettivamente migliori nel senso di portarti diritto al problema.

— Mike Dunlavey,

@Kristof: Ecco il tipo di problema in cui la pausa casuale non va bene, dove se fai un'istantanea in tempo e la studi, non puoi dire il motivo di ciò che sta facendo. Esempio: elaborazione basata sui messaggi, in cui non è possibile sapere da dove è stato inviato il messaggio o perché o con quale frequenza. Un altro esempio: protocolli asincroni, in cui vengono scambiati i messaggi, e sembra che stiamo sempre aspettando l'altro ragazzo. Per l'elaborazione sincrona, i profiler possono misurare meglio, ma è meglio trovare una pausa casuale .

— Mike Dunlavey,

14

Quale tipo di strumento di programmazione pensi sia il più sottovalutato? Motiva la tua risposta.

Il compilatore

La maggior parte delle persone non si prende il tempo per capire cosa fa il loro compilatore preferito. Sentono solo che trasforma il codice in un programma eseguibile e questo è il più lontano possibile. Nella maggior parte dei moderni, ci sono diverse configurazioni che puoi inserire in esso per farlo fare ciò di cui hai bisogno. Ecco un esempio, scommetto che metà degli sviluppatori nel tuo ufficio non hanno idea di come impostare l'avviso come livello di errore (supponendo che ne abbia effettivamente uno). Quali opzioni devi avere per generare simboli di debug? Quali ottimizzazioni (o di quale livello) vuoi che faccia. L'elenco continua.

— Kevin
fonte

3

@Kevin: e aggiungerei dei modi per scrivere il codice per fare in modo che il compilatore esegua i controlli per te (per i linguaggi digitati staticamente). La maggior parte degli sviluppatori usa i tipi di shelf (come la stringa) per rappresentare qualsiasi tipo di informazione, dove potrebbe definire tipi semplici ma incompatibili per dati non correlati ...

— Matthieu M.

@Matthieu M Anche questo è un buon punto. Molte persone dimenticano i modi semplici per aiutarti.

— kemiller2002,

3

Ogni avvertimento del compilatore è un dono prezioso. Non ignorarli! Chiedere di più! -La guerra dovrebbe essere obbligatoria.

— Kristof Provost,

@Kristof: -pedantic -Wall -Wextra -Werror... anche se può essere difficile costruire qualcosa allora: p

— Matthieu M.

Forse sono solo io, ma se "metà degli sviluppatori" non sa cosa dire dei simboli di debug "non è un'esagerazione, è piuttosto scoraggiante.

— Kizzx2,

10

Il tuo cervello. Altri strumenti non avrebbero molto significato senza di essa.

— jnevelson
fonte

4

Ho reso il mio per lo più inservibile a volte.

— David Thornley,

3

"più o meno dimenticato": -S

5

Direi che è sottovalutato. Troppe persone sono sempre alla ricerca di scorciatoie in modo che non debbano pensare. Non c'è rimpiazzo per il senso comune e la logica e gli strumenti non possono sostituirlo.

— jnevelson,

2

Sono d'accordo con Jonathan, il cervello è spesso sottovalutato. In effetti, troppi programmatori si affidano ai pochi trucchi che conoscono invece di uscire dalla scatola e di tanto in tanto scrivere un caso di prova su misura (economico e sporco, buttare via la classe) e strumento di prova per indagare sul problema a portata di mano. In molte occasioni ho fornito agli sviluppatori i mezzi per andare oltre il loro stato di pensiero e risolvere i loro problemi con non più di poche domande.

— asoundmove,

1

Alcuni commenti mi hanno fatto cambiare opinione, +1 :)

— Anto

10

Buon vecchio:

print

A volte è utile un debugger o un profiler o un diagramma di flusso UML. E a volte ti fanno impazzire. Mi ritrovo sempre a ricadere sull'uso delle istruzioni di stampa (o trace o NSLog o what-have-you) solo per assicurarmi che il mio codice stia facendo quello che penso stia facendo quando penso che lo stia facendo.

— JRW
fonte

Penso che questo dipenda dalla lingua e dal debugger. I tipi di debugger offerti dalla maggior parte degli IDE decenti al giorno d'oggi per le lingue popolari ti consentono di fare le cose molto più facilmente delle dichiarazioni stampate.

— Billy ONeal,

8

Semplici script vecchi ... non importa quante lingue di prossima generazione sviluppiamo, facciamo ancora molto affidamento sugli script anche la maggior parte delle attività quotidiane possono essere realizzate scrivendo alcune righe di script.

— Gaurav Sehgal
fonte

1

Vedi ... Non sarei d'accordo con questo. Sì, gli script possono automatizzare alcune attività. Ma spesso vengono portati ben oltre il punto di senso fino al punto in cui diventano solo un grosso luccio di spaghetti.

— Billy ONeal,

1

Vero, i grandi script sono raccapriccianti da guardare e uno potrebbe usare perl o python per questo. Anche se sono ancora bravi a fare piccoli lavori.

— Gaurav Sehgal

@Billy Usa Python. Risolto il problema degli spaghetti :)

— Evan Plaice,

7

Penna e lavagna.

Non puoi battere la tecnologia bassa quando cerchi di spiegare qualcosa.

— Andy Lowry
fonte

3

Risposta duplicata - programmers.stackexchange.com/questions/57148/…

— ChrisF

Potrebbe essere una risposta duplicata, ma guadagna il mio voto separato per la lavagna.

— Carson Myers,

Hmm, abbastanza sicuro che non sia stato un duplicato quando l'ho creato, molto strano. Lo cambierò in Penna e lavagna.

— Andy Lowry,

6

ack . È come grep -r, ma è progettato per la ricerca attraverso il codice sorgente.

— Peter Mortensen
fonte

5

Perl e altri linguaggi di scripting. Ottimo per attività un po 'troppo complicate per strumenti della GUI come Agent Ransack.

— Kevin Cline
fonte

1

Non sono sicuro che siano sottovalutati ...

— Anto

3

Decisamente sottovalutato ... specialmente Perl. È un lang. molto ben progettato con il motto Keep Things Simple ... come tale, non ha prezzo per compiti rapidi che devono solo essere fatti.

— Rook,

@Rook: Non sono sicuro di come una lingua con più di 100 operatori possa essere considerata "semplice". Utile, forse. Ma non "semplice".

— Billy ONeal,

@Billy - Semplice non esclude potente. Trovo i calcolatori semplici. Non so cosa faccia la metà delle 300 funzioni sulla mia, ma ciò non ne riduce la semplicità.

— Rook,

4

Scorciatoie da tastiera che consentono il refactoring rapido, frequente e sicuro. Imparare come estrarre (o incorporare ecc.) Variabili, metodi, costanti o classi con la semplice pressione di alcuni tasti ha cambiato radicalmente il modo in cui codifico. Rifatterai frequentemente (cioè abbastanza) solo quando il costo è minimo, quindi rendere queste scorciatoie una seconda natura è essenziale per scrivere e mantenere un buon codice per quanto mi riguarda.

Quindi, in generale, usa buoni strumenti (IDE / editor) e impara come ottenere il massimo dalle funzionalità che forniscono.

Successivamente verranno test unitari e TDD, per mantenere testabile il codice e prevenire il timore di refactoring.

Usa questi e ti sposterai facilmente verso la scrittura di un codice gestibile corretto conforme al principio DRY e auto-documentante.

— Camice
fonte

4

I test unitari offrono i seguenti vantaggi:

Gli sviluppatori diventano i primi clienti del codice. Più rapidamente viene rilevato un bug, meno costoso è riparare. I bug possono essere rilevati prima di una compilazione, installazione o distribuzione .
Il test cambia la tua prospettiva sul codice. Il design è chiaro? Gestisce custodie angolari?
L'effetto Hawthorne migliorerà la qualità, semplicemente annunciando che un team sta pubblicando metriche di qualità / test.
Anche se i test non sono controllati nel controllo del codice sorgente, possono essere un ottimo modo per esplorare e apprendere nuovi terreni.
Un'alta probabilità di meno bug!

— Michael Easter
fonte

4

Generatori di codice

I generatori di codice possono creare una grande quantità di codice efficiente e privo di bug da una semplice definizione. ORM usi di tipo sono i più ovvi per la creazione di classi di accesso ai dati, ma ci sono molti più usi potenziali.

Il supporto per la generazione di codice sembra essere ancora agli inizi sia dal punto di vista del programmatore che del framework, ma credo che sia qualcosa che vedremo sempre di più. In .NET puoi iniziare a dilettarti con le cose CodeDOM .

— konrad
fonte

Mi piace scrivere generatori di codice, non la cosa più semplice da ottenere, ma davvero utile.

— Zaccaria K,

3

Uso AgentRansack pesantemente. È di grandissimo aiuto nella ricerca di migliaia di file molto rapidamente. Mi ha risparmiato così tanto tempo, ma non conosco molti programmatori che lo sappiano o lo utilizzino.

— JakeRadakovich
fonte

3

Metodi formali

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

È difficile sopravvalutare la loro importanza. Ogni ciclo e ogni istruzione if inizia come un'idea che richiede una sorta di "prova". La maggior parte dei programmatori fa questa prova il più delle volte nelle loro teste. Chiedete cosa fa l'istruzione if e possono articolare - in modo solido e logico - quali sono le scelte e perché le scelte sono complete, coerenti ed esclusive.

Ma alcuni sembrano indovinare casualmente. Hanno bisogno di più aiuto e i metodi formali potrebbero essere il tipo di aiuto di cui hanno bisogno.

È solo algebra (e calcolo) per il codice. Niente di troppo complesso o sofisticato.

— S. Lott
fonte

Li ho trovati spesso utili per ottenere le cose semplici in modo da poterle fare affidamento mentre eseguo il debug delle cose più complicate. La mia esperienza è che i metodi formali eliminano abbastanza bene i bug sottili, lasciando solo quelli evidenti e palesi che vengono facilmente catturati dai test.

— David Thornley,

3

Motivi di design fisico come lasciare la sedia per una rapida corsa alla luce del sole e all'aria aperta mantengono il nostro cervello al massimo della bellezza.

— Joe Chrysler
fonte

3

Beh, è Half Life 2 (inserisci qui il tuo gioco preferito). Se ho un problema che non riesco a risolvere, esco e inizio a giocare con il mio gioco preferito e all'improvviso mi viene in mente la soluzione. Quindi, ad essere onesti, non è un gioco o qualcosa del genere ma lo fa qualcos'altro . Vedo spesso persone sedute su un problema per ore senza risolverlo e tutto ciò che dovrebbero fare è mettere il cervello offline per un breve periodo.

— Adam Arold
fonte

3

Stack Overflow : rapido aiuto esperto quando sei bloccato

sito di domande e risposte per programmatori professionisti ed entusiasti. È costruito e gestito da te come parte della rete Stack Exchange di siti di domande e risposte. Con il tuo aiuto, stiamo lavorando insieme per creare una libreria di risposte dettagliate ad ogni domanda sulla programmazione ...

— moscerino
fonte

+1, ma non molto più sottovalutato

— MAK

4

forse anche sopravvalutato, o almeno abusato

— Anto

3

Penso che sia Notepad / TextPad / semplici programmi di modifica del testo. Ognuno ha un momento in cui ha bisogno di una soluzione rapida che non richiede l'apertura di un IDE e necessita solo di una modifica rapida. E tutti i computer hanno una sorta di semplice programma di modifica del testo.

— Peter Mortensen
fonte

2

Asserzioni e un bene alwaysAssert() funzione. IMHO questi sono più importanti dei test unitari, poiché i test unitari possono trovare bug solo nei casi specifici che si pensava di testare. Se lo stesso programmatore scrive il codice e i test, probabilmente perderà gli stessi casi limite in entrambi. Inoltre, a volte i test unitari sono impraticabili perché l'ambiente in cui il componente funziona e / o i dati su cui opera è troppo complicato per elaborare un caso di prova inventato per.

La bellezza delle asserzioni sta nella loro capacità di documentare le assunzioni e testarle su input non inventati . Se una di queste ipotesi è errata, il tuo codice fallisce rumorosamente invece di "funzionare" ma producendo risultati sottilmente errati. Inoltre non si avvicina alla radice del problema di quanto non farebbe senza le affermazioni. In pratica, se affermi esplicitamente abbastanza presupposti su un pezzo di codice e tutti questi presupposti sono corretti, il codice è di solito corretto.

Una lamentela comune riguardo alle asserzioni è che possono essere disattivate. IMHO ogni linguaggio o libreria standard dovrebbe avere una alwaysAssert()funzione o un equivalente approssimativo che fa la stessa cosa assertma che non può essere disattivato. Questo può essere usato per verificare le ipotesi in aree di codice non performanti, in cui i benefici della disattivazione delle asserzioni sono trascurabili.

— 2 giri
fonte

Concordato. Ma purtroppo strumenti semplici ma efficienti, come questo, sono spesso sottovalutati.

— Peter Mortensen,

2

Il tasto F1. - Utile per i programmi che non conosci e per i programmi su cui stai lavorando. (Supponendo che si tratti di un'applicazione di grandi dimensioni.)

Potente filtrare i problemi se gli utenti segnalano bug in base alla loro interpretazione di come dovrebbe funzionare il software. Certo, potrebbe essere che il design stesso fosse difettoso. Ma questa è un'altra storia.

— Jeremy Edwards
fonte

2

Entrambi sottovalutati e anche sottoutilizzati.

— Tipo anonimo

Molto sottovalutato dagli sviluppatori dell'applicazione che stai utilizzando in questo momento; in quanto tale, la guida contiene informazioni poco o per nulla utili.

— colpì il

2

Varie utility di base UNIX, ma principalmente finde occasionalmente grepo ed. La capacità di trovare cose in nidi profondi di file è preziosa, in particolare quando si eredita improvvisamente una base di codice e si deve risolverlo. Anche se detto codice è ben documentato, probabilmente dovrai cacciare e una forte comprensione di findciò lo uccide.

— Kojiro
fonte

2

Curiosità

Chiamalo "Indovinello di programmazione". Qual è uno strumento rispetto alla persona che lo brandisce? Il desiderio di sapere come e perché qualcosa funziona o non funziona espande la propria conoscenza più di qualsiasi strumento specifico e questo è vero al di là della programmazione.

— Tommaso
fonte

2

Ctrl + C    
Ctrl + V

Risparmiato innumerevoli ore in tutto il mondo!

— gAMBOOKa
fonte

1

Coda

Tail può essere utilizzato per monitorare il file di output del registro del programma in tempo reale. È stato di grande aiuto durante lo sviluppo di sistemi che non forniscono ad altri mezzi di lettura del registro.

I programmi di esempio sono;

coda per Unix.
coda per Mac.
BareTail per Windows.

— dichiarazione
fonte

Mac OS X è un sistema UNIX. Non c'è bisogno di menzionarlo separatamente.

— destra

0

Una volta ho messo insieme un generatore di grafici per le chiamate Perl. È stato estremamente utile, ma è caduto pesantemente su codice non procedurale o routine fuori file.

— Paul Nathan
fonte