Clean up repetitive code in App definition #1749
-
What are you trying to do?I have a simple app with a repetitive argument structure. I am happy with how things work, but I am wondering if there is a way to clean it up (reduce boilerplate). What have you tried already?This is my current code: let matches = App::new("MyApp")
.arg(
Arg::with_name("our_test_outputs")
.long("our-test-results")
.help("path to output of running our tests on their solution")
.takes_value(true)
.required(true),
)
.arg(
Arg::with_name("their_test_outputs")
.long("their-test-results")
.help("path to output of running their tests on our solution")
.takes_value(true)
.required(true),
)
.arg(
Arg::with_name("submission")
.long("submission")
.help("path to submission/Cargo.toml")
.takes_value(true)
.required(true),
)
.arg(
Arg::with_name("output")
.long("output")
.help("path where results.json will be written")
.takes_value(true)
.required(true),
)
.arg(
Arg::with_name("lcov")
.long("lcov")
.help("path to lcov.info")
.takes_value(true)
.required(true),
)
.arg(
Arg::with_name("scores")
.help("path to scores.yaml")
.long("scores")
.takes_value(true)
.required(true),
)
.get_matches()
let output_path = value_t!(matches, "output", PathBuf)?;
let lcov_path = value_t!(matches, "lcov", PathBuf)?;
let scores_path = value_t!(matches, "scores", PathBuf)?;
let our_test_outputs = value_t!(matches, "our_test_outputs", PathBuf)?;
let their_test_outputs = value_t!(matches, "their_test_outputs", PathBuf)?;
// coerce to paths
let output_path = output_path.as_path();
let lcov_path = lcov_path.as_path();
let scores_path = scores_path.as_path();
let our_test_outputs = our_test_outputs.as_path();
let their_test_outputs = their_test_outputs.as_path(); Is there an idiomatic way to simplify this code? Can I, for example, set all arguments as |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Not really and yes at the same time.
Yes, but you may not like it.
No. Just no. I really don't like global switches that drastically change behavior of the library. There is alternative way to make an App::new("MyApp")
.arg(Arg::from_usage("--our-test-results <path>")
// separate call since the help string is quite lengthy
.help("path to output of running our tests on their solution")
)
// the help line has been incorporated since it's fairly short
.arg(Arg::from_usage("--scores <path> 'path to scores.yaml'"))
/// etc...
.get_matches(); Looks trim, but Use #[derive(StructOpt)]
struct Opt {
/// path to output of running our tests on their solution
#[structopt(long)]
our_test_results: PathBuf,
/// path to output of running their tests on our solution
#[structopt(long)]
their_test_results: PathBuf,
/// path to submission/Cargo.toml
#[structopt(long)]
submission: PathBuf,
/// path where results.json will be written
#[structopt(long)]
output: PathBuf,
/// path to lcov.info
#[structopt(long)]
lcov: PathBuf,
/// path to scores.yaml
#[structopt(long)]
scores: PathBuf
} |
Beta Was this translation helpful? Give feedback.
-
#[derive(StructOpt, Debug)]
struct Opt {
/// path to output of running our tests on their solution
#[structopt(long)]
our_test_outputs: PathBuf,
/// path to output of running their tests on our solution
#[structopt(long)]
their_test_outputs: PathBuf,
/// path to submission/Cargo.toml
#[structopt(long)]
submission: PathBuf,
/// path where results.json will be written
#[structopt(long)]
output: PathBuf,
/// path to lcov.info
#[structopt(long)]
lcov: PathBuf,
/// path to scores.yaml
#[structopt(long)]
scores: PathBuf,
/// path to labels.yaml
#[structopt(long)]
labels: PathBuf,
}
fn main() {
let opt = Opt::from_args();
// coerce to paths
let output_path = opt.output.as_path();
let lcov_path = opt.lcov.as_path();
let scores_path = opt.scores.as_path();
let labels_path = opt.labels.as_path();
let our_test_outputs = opt.our_test_outputs.as_path();
let their_test_outputs = opt.their_test_outputs.as_path();
} |
Beta Was this translation helpful? Give feedback.
Not really and yes at the same time.
Yes, but you may not like it.
No. Just no. I really don't like global switches that drastically change behavior of the library.
There is alternative way to make an
Arg
-Arg::from_usage
(Arg::from
in upcoming 3.0).Playground