Este o bună practică de programare să creezi fișiere fără extensie? [închis] (Inginerie software, Python, Standarde De Codare)

Tim a intrebat.

Adesea stochez date în fișiere externe atunci când codific în Python.

Ar trebui să le salvez întotdeauna cu o extensie – de ex. .txt?

Există vreun motiv pentru a nu (în afară de economisirea de octeți) pentru a nu da extensia? Știu că va fi doar codul meu care va citi acest fișier (nu ar exista niciun motiv pentru ca cineva să îl deschidă).

Comentarii

  • Veți transfera aceste fișiere între calculatoare? Fișierele conțin text? Este textul codificat cumva? Este vorba de date binare brute? Nu există nicio modalitate de a răspunde la această întrebare așa cum este scrisă, deoarece se reduce la părerea unui programator. – user22815
  • Ce sistem de operare folosiți? –  > Por user1717828.
  • Aceste date stocate sunt similare cu datele de configurare? O modalitate standard de a face acest lucru este de a crea un director pentru fișierele dvs. într-un loc adecvat în directorul de pornire al utilizatorului care rulează, de exemplu ~/.myprog. După ce ați creat acest director, puteți stoca acolo datele persistente ale programului dvs. folosind orice convenție de denumire care vă convine. –  > Por Brandin.
  • @user1717828 Programare pe Linux, scris pentru a funcționa pe toate cele 3. – – user1717828  > Por Tim.
  • @Snowman 1. Nu 2. Da 3. Nu 4. 4. Nu  > Por Tim.
1 răspunsuri
Mike Nakis

Voi răspunde la această întrebare pentru oamenii în general de acolo, dar ar trebui să subliniez mai întâi că, chiar și pentru tine în special, probabil că nu există un astfel de lucru ca „doar codul meu va citi acest fișier”. Vor fi momente în care va trebui să vizualizați sau să editați fișierul, nu? Atunci, pe lângă propriul cod, editorul dvs. preferat va citi și el acel fișier, cel puțin.

Dacă veți folosi numai instrumente de linie de comandă (și nu vă pasă dacă alegerile dumneavoastră vă condamnă să folosiți întotdeauna numai instrumente de linie de comandă), atunci fișierele fără extensii ar trebui să fie în regulă. Aceasta deoarece instrumentele de linie de comandă respectă paradigma verb-nume a designului interfeței cu utilizatorul, conform căreia mai întâi alegeți verbul (introduceți numele comenzii care urmează să fie executată) și apoi alegeți substantivul asupra căruia va acționa verbul (introduceți numele fișierului ca argument de linie de comandă pentru comandă.) Astfel, în esență, calculatorul nu este împovărat de faptul că trebuie să țină evidența tipului fiecărui fișier și, în schimb, această sarcină este delegată servitorului de încredere al calculatorului, omul.

Dacă aveți de gând să utilizați un sistem de operare cu interfață grafică cu utilizatorul inventat în ultimii 40 de ani sau cam așa ceva, care, după toate probabilitățile, urmează paradigma substantiv-verb, atunci veți avea nevoie, cel mai probabil, de extensii de nume de fișiere. Vedeți, paradigma substantivului-verb vă permite să selectați mai întâi unul sau mai multe fișiere și apoi să efectuați fie acțiunea implicită asupra lor (dublu clic, de obicei, editează), fie să alegeți o acțiune dintr-o listă de acțiuni (meniul contextual) despre care sistemul de operare știe că se aplică fișierelor de acel tip. Desigur, pentru ca acest lucru să funcționeze, sistemul de operare trebuie să cunoască tipul fiecărui fișier. Problema este că, dintr-un motiv pe cât de nefericit, pe atât de insondabil, sistemele de operare tind să nu dispună de niciun mecanism formal pentru a cunoaște tipul fiecărui fișier stocat în cadrul sistemelor lor de fișiere, astfel încât se bazează pe trucuri precum extensia numelui de fișier pentru a ghici tipurile de fișiere. Așadar, dacă doriți să profitați de faptul că sistemul de operare vă poate scuti de clicuri și apăsări de taste suplimentare prin cunoașterea tipului fiecărui fișier, atunci extensiile de nume de fișier sunt prietenele dumneavoastră.

În afară de asta, nu, nu există niciun motiv tehnic obligatoriu pentru a da întotdeauna fiecărui nume de fișier o extensie. Este doar un lucru util de avut.