Ci sono alternative accettate per avere lo standard di stampa (ad esempio copyright, OSS, xport ctrl, classificazione) nel codice sorgente stesso?

Question

Ci sono alternative accettate per avere lo standard di stampa (ad esempio copyright, OSS, xport ctrl, classificazione) nel codice sorgente stesso?

#1 da (3 voti)

1

Si sta facendo sempre più fatica a mantenere aggiornato l'intestazione "boilerplate" del codice aziendale in base a classificazioni e modelli da un'applicazione esterna, portando a "modifiche del codice sorgente" e al nuovo test a causa dell'aggiornamento delle decine di migliaia di diritti d'autore di file. E di tanto in tanto il modello di licenza cambia.

È costoso e demotivante perché gli strumenti di gestione del ciclo di vita dell'azienda portano anche le informazioni, rendendole ridondanti. Ma ci sono alternative ampiamente accettate?

Se il codice sorgente è in un repository (ad es. git / mercurial), il repository stesso potrebbe contenere il boilerplate? È possibile aggiungere un file di codice al momento del pagamento: cat copyright.txt license.txt source.code ?

Ci sono filesystem che permettono ai file di portare queste informazioni? Codice sorgente e / o binari?

Altre soluzioni?

licensing copyright

posta Andreas 10.12.2018 - 11:10

fonte

1 risposta

Leggi altre domande sui tag licensing copyright

Come mantenere la familiarità con la tecnologia / lingua / funzione precedentemente lavorate [chiusa] c # Che problema si verifica quando uso la classe statica per il database di accesso?

score 3 · Accepted Answer

Dal punto di vista di uno sviluppatore, quei commenti di intestazione sono spazzatura pura al 100%. Ogni volta che apro un file, devo scorrere oltre tutte quelle assurdità per arrivare al codice attuale. Quindi sì, esiste un'alternativa ampiamente accettata: non inserire i commenti di intestazione nei file sorgente.

Certo, la vita non è così semplice: non sono solo gli sviluppatori che decidono queste cose. La tua azienda potrebbe imporle per motivi commerciali o legali. Quindi, diventa un caso che tu abbia una conversazione con quelle altre parti su come raggiungere un compromesso tra minimizzare la spazzatura, rispetto a soddisfare quelle esigenze commerciali e legali. Le scelte ovvie sono:

Metti tutte queste informazioni in un singolo file LICENCE nella directory principale del tuo progetto e non hai commenti di intestazione nei singoli file sorgente. Questo è un approccio comunemente usato per molti progetti su GitHub per esempio. Se puoi adottare questo approccio, è di gran lunga l'alternativa migliore. Mantiene puliti i file di origine e significa che è necessario modificare un solo file quando le regole cambiano.
Inserisci tutte le informazioni comuni in un singolo file e inserisci un riferimento a quel file in tutti i commenti di intestazione. Ciò non elimina completamente la necessità di intestazioni, ma le mantiene piccole ed evita la necessità di modificare i file di origine quando i dettagli della licenza cambiano.
Usa gli script per rimuovere le intestazioni dai file di origine al momento del checkout e ad esempio usa git git per reinserirle al momento del check-in. Questa è una strategia rischiosa poiché fa affidamento su chiunque abbia gli stessi script e li esegue in modo affidabile e sul script che identificano correttamente l'intestazione durante la loro rimozione. Inoltre non affronta la necessità di cambiare i file sorgente quando cambia il contenuto delle intestazioni. Ma se nessuna delle due precedenti opzioni è valida nel tuo caso, questa potrebbe essere l'unica opzione disponibile per te.