Sì, dovresti.

Primo, la maggior parte del software scientifico è terribile. Sarei molto sorpreso se il tuo fosse peggiore della media: il solo fatto che conosci i modelli di progettazione e la differenza tra ricorsione e cicli suggerisce che è meglio.

In secondo luogo, è improbabile che tu abbia l'incentivo o la motivazione per renderlo migliore a meno che, o fino a quando, non sia necessario a qualcun altro (o a te in 6 mesi). Renderlo aperto ti dà quell'incentivo.

Potenziali vantaggi: possibili nuovi collaboratori, correzioni di bug, estensioni, pubblicazioni.

Potenziali svantaggi: riduzione del tempo (mantenimento del codice o risoluzione di problemi per altre persone), ottenere scavato. Sarò chiaro: non prendo molto sul serio nessuno di questi aspetti negativi.

Vorrei ripulirlo un po 'e condividerlo. Ho rilasciato molto codice nel corso degli anni e non ho rilasciato codice anche per i motivi che fornisci.

Analizzalo e commentalo, a qualsiasi livello tu possa. Lascia in "tentativi falliti" e commentali come tali. Spiega perché hanno fallito e cosa hai provato. Questa è un'informazione MOLTO utile per le persone che vengono dopo di te.

Crea un file README che dice che lo rilasci su richiesta nella speranza che aiuti qualcuno. Dì che sai che il codice è brutto, ma speri comunque che sia utile.

Troppe persone trattengono le cose perché non è perfetto!

Sì! Soprattutto se la tua carta è ad es. su un algoritmo nuovo / migliorato che hai implementato, o fai un'analisi significativa dei dati non standard, o praticamente qualsiasi cosa in cui riprodurre i tuoi risultati significhi reimplementare il tuo software.

Gli articoli raramente hanno spazio per dare di più di un contorno. So di aver speso (= sprecato) troppo tempo cercando di implementare algoritmi da documenti che tralasciavano dettagli critici (ma non strettamente rilevanti per l'articolo).

¿Pensi che il tuo codice sia disordinato? Ho visto (e ho tentato di lavorare con) codice che mi ha fatto venire gli incubi:

• Cinque livelli di if True annidati, sparsi in punti casuali nel codice.
• Crea un array di zeri, convertilo in gradi, prendi il coseno e torna in radianti. Quindi, butta via il risultato.
• Su un software in forte sviluppo, l'elenco delle "architetture supportate" è così antico (e lo dicono loro stessi) sarebbe difficile mettere le mani su uno di questi computer al giorno d'oggi.
• Funzionalità non funzionanti o modificate diverse versioni fa, ancora consigliate nei documenti.
• Codice che va dall'utilizzo di un formato standard di input a un formato proprio. Come generarlo? Nessuno lo sa veramente e gli sviluppatori danno una risposta.
• Versioni che non si compilano nemmeno. (L'hai anche testato?)
• Menu della GUI a cui devi accedere in un ordine specifico. Altrimenti, si ottiene un errore di segmentazione e si deve ricominciare dall'inizio.
• Percorsi hard-coded sparsi nel codice. Quindi devi passare da un file all'altro per trovare e modificare tutte le occorrenze di / home / someguy / absurd_project / working / al tuo.

E, il mio preferito personale , un certo programma di migliaia di righe di codice, utilizzava solo commenti per eliminare bit casuali di codice, tranne uno:

Qui perforiamo le carte.

Tuttavia, non ho idea di cosa stesse facendo.

E questo sta solo lasciando al di fuori delle classiche cose di buona pratica, come le variabili di una lettera in tutto il codice, algoritmi non specificati da nessuna parte ...

Se sei preoccupato per la qualità del tuo codice, probabilmente significa che ti interessa abbastanza da averlo reso migliore della media. Se aspetti che il codice sia pulito, potrebbe non uscire mai e i tuoi contributi scientifici andranno parzialmente persi.

A mio parere, le cose importanti di cui dovresti preoccuparti, in ordine, sono:

1. Formati di input e output. Usa gli standard quando disponibili, rendilo semplice quando non lo sei. Semplifica l'utilizzo del programma come una scatola nera.
2. Commentato. Brevi descrizioni delle funzioni, rapida panoramica dell'algoritmo.
3. Leggibilità. Utilizzo di codice idiomatico, buoni nomi di variabili ...
4. Struttura. Questo è più facile quando sai cosa vuoi fare, che di solito non è il caso del codice di ricerca. Solo se c'è interesse nella comunità, puoi prendere in considerazione il refactoring.

Quindi, rilascia il tuo software ogni volta che hai 1 (2 e parte di 3 dovrebbero entrare mentre lo stai scrivendo) .

Stai chiedendo se condividere software di bassa qualità darebbe una cattiva impressione di te. Penso che la condivisione di software dia una buona impressione.

1. In quanto scienziato informatico, mi piace quando i colleghi rendono disponibile il loro codice sorgente. Mi rende più propenso ad approfondire il loro lavoro, magari contattarli, magari citarli, perché c'è un altro artefatto con cui interagire (non solo la carta, ma anche il codice).

2. Quando un articolo riporta un risultato "provato" dal codice sorgente, ma il codice sorgente non è pubblico, spesso mi chiedo se il risultato sia reale. Guardare il codice sorgente (o solo la disponibilità del codice sorgente, senza mai guardarlo) può convincermi.

Quindi condividere il tuo codice sorgente, orribile o no, mi darebbe sempre una buona impressione di te.

Ora, se vuoi impressionare ancora di più, sarebbe utile ...

... se reagisci ai problemi o tira richieste su un sito come github, cioè quando vedo che altri cercano di contattarti e tu reagisci.

... se il tuo codice contiene un file readme che collega le affermazioni del tuo articolo alla fonte codice. In questo modo, quando leggo il documento e voglio saperne di più, posso usare il file readme per passare alla posizione appropriata nel codice. Frasi tipiche di un tale file readme potrebbero essere: "L'algoritmo della sezione 3.2 del documento è in file algoritmo / newversion / related / secondtry / foo.c" o "Per ripetere la corsa con il piccolo set di dati descritto nella sezione 2 il giornale, corri "make; make second_step; foo_bar_2 dataset / christmas.dataset. Questa esecuzione richiede circa 2 giorni sul mio laptop ".

Potresti anche essere interessato a CRAPL (Community Research and Academic Programming License) di Matthew Might, disponibile su http://matt.might.net/articles/crapl/. Contiene questo termine: "Accetti di tenere l'autore libero da vergogna, imbarazzo o derisione per qualsiasi hack, kludge o atto di fede trovato all'interno del Programma". Non mi è chiaro se questa "licenza" abbia qualche effetto legale, ma l'intento è chiaro: rilascia il tuo brutto codice e non pensare male al brutto codice degli altri.

Relativamente tangenzialmente, affronterò come condividere il software date le tue preoccupazioni (non dovresti condividere il software per il quale hai già una risposta).

Mettere i tentativi falliti nel controllo della versione in modo efficace significa che nessuno li vedrà mai. Il modo in cui gestisco questo è inserire ogni tentativo in un metodo e ogni tentativo fallito in un metodo separato:

  def main (): get_foobar (x, y) def get_foobar (): return x ** ydef get_foobar_legacy_1 (): "" "Questo tentativo non ha funzionato per i valori > 100" "" return x + ydef get_foobar_legacy_2 (): "" "Questo tentativo non ha funzionato i mercoledì di settembre" "" return x - y  

Secondo i commenti seguenti, potrebbe essere una buona idea mettere questi metodi in una classe separata FailedAttempts o BadIdeas. Questo ha il bell'effetto di compartimentare le varie fasi del processo secondo le effettive necessità. Trovo che i programmatori di computer spesso sappiano quando spezzare la logica in un metodo e quando no, ma gli scienziati informatici spesso no. Questo approccio aiuta gli scienziati informatici a interrompere un metodo quando necessario.

Ovviamente dovresti condividere il codice sorgente.

Dal punto di vista accademico, un risultato basato su software che utilizza codice non immediatamente disponibile non è molto prezioso, poiché come potrebbero altre persone verificare le tue affermazioni, se necessario? Ti aspetti che programmino da soli per questo scopo? La condivisione dei soli file binari è molto meno preziosa e spesso porta ad incubi per le persone che cercano di eseguirli.

Penso che dovresti condividerlo. Prima di tutto dovresti fare un po 'di pulizia di base. (es: nessun codice precedente che non viene più utilizzato; nessun codice nei commenti; modo valido per commentare e così via) Inoltre se metti un po 'di "da fare" nel codice gli altri possono vedere che eri fuori tempo e possono vedere le tue intenzioni. (es .: todo: questo dovrebbe essere cambiato in enum) Penso anche che dovresti condividere la parte più importante dei tuoi algoritmi. Quando condivido un codice non ho mai condiviso parti non importanti. Tutti possono gestire la lettura / scrittura di file, la comunicazione tra thread, gui e così via. Ma non condividere codice illeggibile. Non avrebbe senso. Quindi penso che la via di mezzo sia la migliore tante volte. :-)

Parla con alcuni dei professori del tuo dipartimento di informatica. Vedi se qualcuno di loro sta cercando un progetto in cui gli studenti possano ripulire il codice disordinato per renderlo più presentabile.

Per gli studenti che revisionano il codice, questa può essere una buona esperienza di apprendimento. Cosa succede quando i programmatori programmano con una mentalità basata sui risultati - o sui risultati solo ? Lo vedranno in prima persona. Possono anche applicare alcune di quelle migliori pratiche che hanno imparato. E potrebbero essere motivati ​​a fare un lavoro particolarmente buono sapendo che altri professionisti sono già interessati a vedere il codice.

Un professore potrebbe persino trasformare questo in un concorso, in cui team di studenti provano tutti a rivedere il software e il miglior risultato viene condiviso con il resto del mondo.

Se i loro sforzi di refactoring falliscono, non sei più indietro di quanto eri. In tal caso, le dichiarazioni di non responsabilità sono una cosa meravigliosa. Condividi semplicemente il codice, ma aggiungi un avvertimento: "Non è carino. Quando ho scritto questo, stavo cercando di portare a termine la mia ricerca - non pensavo che sarebbe mai uscito dal mio laboratorio informatico. Ma sei il benvenuto per dare un'occhiata se lo desideri davvero. "

Nelle altre risposte sono stati menzionati molti punti a favore della pubblicazione del codice, e sono completamente d'accordo con loro. Pertanto, poiché è stata discussa la necessità di base della pubblicazione del codice, vorrei integrarla con una lista di controllo di ulteriori punti che devono essere considerati. Molti di questi problemi probabilmente compaiono praticamente in tutti i software accademici, quindi anche se non puoi rispondere "Questo non si applica al mio progetto". a tutti loro, dovresti almeno essere in grado di rispondere "Questo è un problema, ma possiamo risolvere questo problema entro ..." prima di pubblicare il tuo codice:

• Are hai autorizzato la pubblicazione del codice?
  • Puoi garantire di aver utilizzato solo frammenti di codice che sei autorizzato a ridistribuire? O forse hai utilizzato codice da sorgenti non aperte che potresti usare per il tuo software interno, ma che non sei autorizzato a pubblicare? Potete garantire che tutto il codice che avete utilizzato possa essere pubblicato in un unico pacchetto completo? La compatibilità delle licenze non è un problema banale.
  • Puoi scoprirlo in modo affidabile? Hai affidato all'esterno qualche parte del tuo lavoro di codifica o hai integrato codice non pubblicato altrove? Ad esempio, hai supervisionato studenti durante le loro tesi di laurea o hai assunto assistenti di ricerca studenti, il cui lavoro era basato sulla tua ricerca e quindi il loro codice è stato aggiunto alla tua base di codice? Qualche collega ha contribuito con il codice alla tua base di codice? Hanno ricevuto parte del loro codice dagli studenti? Tutte queste persone coinvolte hanno prestato debitamente attenzione ai problemi di licenza (se del tutto avevano le conoscenze per esprimere un giudizio istruito su queste domande sulle licenze)? È ancora possibile determinare l'origine di quali parti del codice? Le persone che hanno contribuito a ciascuna parte lo sanno ancora? Sono ancora "nel raggio di contatto" per te?
  • Il codice è stato sviluppato durante l'orario di lavoro sulla base di fondi di terze parti? In tal caso, i termini del contratto di finanziamento consentono di pubblicare il codice o includono i requisiti per cui il software creato all'interno del progetto finanziato deve essere condiviso esclusivamente con i partner del progetto?
• Disponi di risorse (tempo e altro) sufficienti per spendere gli sforzi per ripulire il codice e i suoi commenti in modo che sia ancora significativo, ma non fornisce alcuna informazione che non deve diventare pubblico?
  • Hai commenti che rivelano chi ha lavorato al codice? Le persone che hanno contribuito al codice sono state ufficialmente autorizzate a lavorare alla rispettiva ricerca, come da finanziamento ? (Gli sviluppatori di software sono ben consapevoli che il lavoro di squadra e il riutilizzo dei componenti sono aspetti fondamentali dello sviluppo del software. Le agenzie di finanziamento, sfortunatamente, sono in genere molto ignare di questo e presumono che se lo sviluppatore A è finanziato dal progetto X e lo sviluppatore B è finanziato dal progetto Y, A lavora esclusivamente su X e B lavora esclusivamente su Y e, rivelando che, wlog, A ha trascorso solo mezz'ora a fare qualcosa che è finito nel progetto Y potrebbe portare a gravi conseguenze, come reclamare parti del finanziamento.)
  • Qualcosa nei dati pubblicati fornisce informazioni sulle particolarità di come è stato svolto il lavoro che non devono diventare pubbliche? Questo è particolarmente importante se l'intera cronologia del commit in un VCS sta per diventare pubblico (o, praticamente, significa che la cronologia del commit non dovrebbe mai essere pubblicata), ma può anche svolgere un ruolo in altre situazioni. Ad esempio: è stato eseguito alcun lavoro sul codice al di fuori degli orari di lavoro ufficialmente assegnati (ad esempio durante i fine settimana)? L'orario di lavoro dimostra che hai lavorato più del limite legale del tuo paese per l'orario di lavoro giornaliero? Gli orari di lavoro rivelano che non hai rispettato le pause previste dalla legge? Gli orari di lavoro rivelano che le persone assegnate ad altri progetti hanno dato dei contributi? Gli orari di lavoro forniscono qualche motivo per diffidare delle affermazioni che hai fatto altrimenti sui tuoi orari di lavoro (ad esempio nei rapporti di successo del progetto che richiedevano un'assegnazione dettagliata degli orari di lavoro a pacchetti di lavoro predefiniti con determinate assegnazioni massime)? Qualcosa rivela che hai lavorato in situazioni in cui non avresti dovuto lavorare (ad esempio durante una riunione di progetto)? Qualcosa dimostra che hai lavorato in luoghi in cui non avresti dovuto lavorare (ad esempio da casa, quando il tuo contratto non ti consente di svolgere l'ufficio a casa, ad esempio per complicazioni relative all'assicurazione)?
  • Sono presenti informazioni segrete nel codice , come password, nomi di account utente o URL che non devono essere conosciuti pubblicamente (perché i server non sono disposti per gestire quantità maggiori di utenti oltre a un numero limitato di persone selezionate a chi è stato fornito personalmente l'URL per la configurazione del test)?
• Il codice è utilizzabile da qualcun altro?
  • Il codice verrà eseguito o richiede grandi sforzi di configurazione? Puoi dedicare lo sforzo richiesto per spiegare quale configurazione è necessaria?
  • Il codice può essere compilato? Hai utilizzato compilatori modificati o personalizzati non ufficiali che non sono accessibili pubblicamente? In tal caso, il codice aggiunge qualcosa oltre a quanto potrebbe essere già fornito come algoritmo di pseudo-codice nei tuoi documenti?
  • Il codice richiede risorse esterne? Il codice essere utile se può accedere a server, librerie o set di dati che non puoi pubblicare insieme al codice per un motivo o per l'altro? È possibile fornire almeno una descrizione di queste risorse o le loro interfacce sono soggette a una sorta di NDA?
  • Il codice apporta modifiche irreversibili ai sistemi su cui viene eseguito? Ad esempio, cambia automaticamente qualsiasi configurazione di sistema (come la sovrascrittura del percorso di ricerca del sistema)? Esegue un accesso di basso livello ai componenti hardware che potrebbero, in determinate costellazioni (che si evitano internamente nelle configurazioni di prova) causare danni permanenti a qualsiasi componente? Potete avvertire in modo affidabile gli utenti del codice di tali possibili effetti collaterali indesiderati?

Certamente. L'unico modo per migliorare la scrittura di un buon software è ottenere feedback (tutti i tipi). Se hai paura del feedback, non andrai molto lontano. Le tre basi per scrivere un ottimo software sono pratica, pratica e pratica.

Ora passiamo alla questione se danneggerebbe la tua carriera se le persone scoprissero che le tue capacità di scrittura di software non sono di prim'ordine. Penso che no, al contrario, ti rispetterebbero per la tua integrità accademica. E non vedo l'ora di collaborare con te.

Puoi semplicemente inviarlo a GitHub e provare a mantenere un progetto nel caso in cui altre persone interessate al tuo progetto possano accedere facilmente al tuo codice e forse possono aiutarti a migliorare il tuo codice.

Sì, dovresti. Dopotutto, il codice sorgente del kernel Linux è un bel pasticcio e questo non ha impedito a molti sviluppatori professionisti di studiarlo e di contribuire con patch e aggiunte. Ricorda anche che il kernel Linux è la base del sistema operativo che esegue i supercomputer più veloci e potenti e la maggior parte dei dispositivi nel mondo.PD: Linus Torvalds, il ragazzo che ha inventato il kernel Linux ha una carriera molto redditizia e di successo che non ha è stato influenzato negativamente o danneggiato in alcun modo dal fatto che il codice sorgente del kernel Linux è disordinato.

Un motivo per cui nessuno ha menzionato il motivo per cui dovresti condividere il tuo codice è che potresti trovare qualcuno che è interessato a collaborare con te, ma che è disposto a dedicare più tempo a ripulire il codice e farlo funzionare su sistemi diversi, ecc. che sul fare lo sviluppo innovativo che hai fatto.

Molte persone trovano questo tipo di lavoro molto soddisfacente e se il tuo codice è veramente utile per loro potrebbero essere felici di farlo. In ogni caso, potresti scoprire che ricevere feedback da persone che hanno provato a usarlo, ma hanno bisogno di qualche tipo di aiuto, è una buona motivazione per renderlo più gestibile / più facile da usare e da capire.

Dovresti assolutamente condividere il tuo codice.

Per ordinare le cose, crea regioni delle stesse parti di codice come fare una regione di un tentativo fallito e spiega perché non è riuscito. Inoltre, se sviluppi in Visual Studio, installa l'estensione "CodeMaid" da Extension Manager e pulisci la tua soluzione completa. Rimuoverà gli spazi e rimuoverà anche i riferimenti inutilizzati migliorando la maggior parte delle cose.

Se sviluppi in C #, condividi il tuo codice con me. Posso anche aiutarti a sistemare le cose :)

Condividilo se vuoi, non condividerlo se non vuoi. So che questo suona irriverente, ma penso che al giorno d'oggi ci sia troppa pressione per "condividere tutto" e le persone cercheranno di renderti colpevole per non aver condiviso, ma in realtà non hai alcun obbligo di condividere nulla.

Metti una dichiarazione di non responsabilità che il codice viene fornito "così com'è" senza promesse di supporto, ecc. Quindi condividi il codice.

Case study: trasformare una nuvola di punti isolati in una superficie a tenuta stagna è un problema pratico estremamente importante, utilizzato ovunque dalla robotica alla visione artificiale all'elaborazione dei dati da sensori 3D come Microsoft Kinect.

La ricostruzione della superficie di Poisson ha 7 anni e da tempo ha smesso di essere lo stato dell'arte per risolvere questo problema. Ma tutti lo usano ancora oggi. Perché? Perché l'autore ha rilasciato il codice e da allora è stato incorporato in un mucchio di popolari librerie di elaborazione della geometria. Il documento ha ora più di mille citazioni.

Sì. Dovresti rilasciare il tuo codice, probabilmente sotto la licenza CRAPL. L'obiettivo è costruire un futuro migliore e il tuo pessimo codice aiuterà le persone a farlo. Un avvertimento è che dovresti documentare come utilizzare con successo il codice abbastanza bene da consentire a qualcuno di avere una discreta possibilità di riprodurre i risultati pubblicati.

E, non preoccuparti: un po 'di codice di ricerca su cui ho lavorato era stato sviluppato da 5 postdoc di indifferente capacità di programmazione per una serie di progetti nel corso di circa 8 anni.

L'elenco delle variabili globali (solo i nomi) era di circa 4 pagine.

Circa un terzo di essi è stato utilizzato per impostare il comportamento predefinito per modificare la funzionalità che funzionava in un dato momento. Un altro 20% erano strutture di dati parallele - il che significa che memorizzavano approssimativamente gli stessi dati - e quindi funzioni nel codice estratte dalle strutture di dati più o meno a caso. Sì. A volte erano fuori sincronia. E a volte doveva essere fuori sincrono.

C'erano circa 50 versioni non documentate, memorizzate in porzioni casuali del server del gruppo - ognuna delle quali serviva almeno a uno scopo specifico - e solo un amministratore manteneva quegli scopi specifici nella sua testa. Era più comune che non avere persone che usavano la versione "sbagliata" per un determinato scopo.

L'uso di procedure ricorsive incredibilmente complesse, ad esempio, per scrivere un file, era standard. Seriamente, poche migliaia di righe per salvare i risultati dell'immagine.

Oh, e i resti di un tentativo macellato di risolvere una perdita di memoria (in realtà una figura invisibile) non creando mai una nuova variabile.

Oh, e il database, quel bel database. Circa la metà dei dati era inutilizzabile a causa di (a) errori di progettazione del database (b) errori di immissione dei dati (nei programmi automatici). Il codice per recuperare i file dal database era lungo diverse centinaia di righe di logica ... Il database stesso era anche così gentile da contenere molte copie degli stessi dati, molte delle quali con collegamenti interrotti tra le tabelle. Vincoli? No. Ho visto uno statistico passare dall'inquietudine alla paura fino alle lacrime fino all'abbandono del database entro un mese dall'affidamento del database ...

C'erano da 0 a 1 modi per utilizzare il software e recuperare i risultati corretti in un dato istante ...

E sì, c'erano gotos.

Oh, e nel tentativo di garantire operazioni opache e non deterministiche, una serie di calcoli è stata eseguita chiamando la GUI pulsanti con richiamate associate.

Circa il 90% di una data funzione non era, in modo abbastanza affidabile, rilevante per il risultato o per il debug del risultato, essendo composto, piuttosto, da progetti a breve termine inseriti e poi mai rimosso. Scherzi a parte, ho scritto una versione completa di funzionalità che funzionava effettivamente che era 1/10 della dimensione ... Le frazioni significative erano funzioni inserite con copia-incolla, molte delle quali differivano l'una dall'altra.

E, no Virginia, non c'è documentazione. O nomi di variabili descrittivi.

Oh, e le dll non documentate, difettose, e le librerie associate - generate usando codice che non esisteva più.

Tutto scritto in Matlab. In termini di pratiche di codifica Matlab, presumi che un uso abbondante di eval sarebbe il momento clou della tua giornata.

Seriamente, il tuo codice non è così male.

Detto questo, se hai fatto qualcosa di veramente utile, potrebbe migliorare la tua carriera rilasciare una versione ripulita in modo che altre persone utilizzino e citino la tua libreria. Se hai appena fatto qualcosa, probabilmente la riproduzione è fin dove ti consiglio di andare.