sharkdp/fd

Design and refactoring / general code quality

Open

#382 aperta il 4 gen 2019

Vedi su GitHub
 (15 commenti) (1 reazione) (0 assegnatari)Rust (1059 fork)batch import
good first issuehelp wanted

Metriche repository

Star
 (42.984 star)
Metriche merge PR
 (Merge medio 15g 23h) (16 PR mergiate in 30 g)

Descrizione

This is intended as a tracking issue for general code quality and design discussions. @sharkdp feel free to close this when you think quality has reached an overall satisfactory level.

To start, I'll quote a recent comment by @sharkdp from a discussion on a PR thread:

There are many things I have in mind that would hopefully help to improve the code quality:

  • Group related functions into impl blocks of appropriate structs such that we don't have to pass around so many parameters.
  • Think about a unified interface for filters (file type, file size, modification data, file extension, ..). Maybe a trait-based interface where the filters would be stored in a Vec<Box<dyn Filter>>.
  • Extract some of the functionality like the OsStr-based path handling into separate libraries / crates.

Guida contributor

Direzione di ricerca
Questo è un meta issue per miglioramenti generali della qualità del codice nel repository fd. Fa riferimento a una discussione PR (#309) e suggerisce di raggruppare funzioni correlate in blocchi impl di struct, creare un'interfaccia di filtro basata su tratti ed estrarre la gestione dei percorsi OsStr in crate separati. Nessun compito concreto è definito, quindi un nuovo arrivato dovrebbe prima identificare un problema specifico di qualità del codice, magari esplorando la codebase per aree che mancano di modularità o documentazione, e proporre un refactoring mirato. Il maintainer (@sharkdp) ha notato che questo issue può essere chiuso quando la qualità è soddisfacente, quindi potrebbe essere necessario un ulteriore input dalla comunità per definire sotto task attuabili.
Tech stack
rust
Dominio
cli
Tipo issue
Refactoring
DifficoltàQuanto dovrebbe essere impegnativa per un nuovo contributor.
4
Tempo stimatoTempo stimato per completare e verificare uno scope piccolo.
Oltre 1 settimana
Stato attivitàQuanto è probabile che la issue sia ancora attiva e reviewable.
Datata
ChiarezzaQuanto chiaramente la issue descrive problema, scope e risultato atteso.
Abbastanza chiara
Prerequisiti
RustExperience with codebase design
Adatta ai principiantiQuanto la issue è adatta a contributor alla prima esperienza.
20