Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Standardize CLI options on dashes or underscores #497

Closed
dchelimsky opened this Issue Nov 4, 2011 · 13 comments

Comments

Projects
None yet
7 participants
Owner

dchelimsky commented Nov 4, 2011

CLI options are inconsistent in format e.g. --fail-fast (with dashes) and --line_number (with underscores). Ideally each option would be listed with dashes, but support both dashes and underscores, but that probably requires hacking into optparse. Short of that, we should standardize on dashes or underscores and deprecate the non-standard ones.

Argument for dashes - they tend to be more standard and are slightly easier to type.

Argument for underscores - they align with the RSpec.configure options, which use underscores because they are method names.

Comments welcome.

Contributor

justinko commented Nov 7, 2011

This is a tough one, but I'd go with dashes. Currently, there are only 2 options that use underscores (one was added by me!): line_number and default_path.

Contributor

twe4ked commented Sep 17, 2012

Argument for dashes - they tend to be more standard and are slightly easier to type.

I think go for dashes, sticking to standards makes things much easier to remember. More people probably know how 'standard' CLI apps work than the amount of people that know the RSpec.configure options.

Member

soulcutter commented Sep 18, 2012

I feel dashes are a CLI convention. Dashes get my vote.

Contributor

alindeman commented Sep 18, 2012

Dashes 👍

Owner

dchelimsky commented Sep 18, 2012

I think this should tie in w/ my comments here: #682 (comment), and this should all be part of the 3.0 effort. Thoughts?

Contributor

patmaddox commented Sep 18, 2012

Is it weird to use underscores where it's an RSpec method name, and dashes otherwise?

Owner

myronmarston commented Sep 18, 2012

I think it'd be weird to use dashes in ruby method names and underscores for the CLI switches. I think choosing one convention for both would create more confusion than it would solve.

Owner

dchelimsky commented Sep 18, 2012

@patmaddox I think so because you probably don't care whether or not it's an rspec method name when you're typing a command.

I think the right thing to do is either only support dashes on the command line or figure out a way to support input of dashes or underscores but only display options with dashes in the optparse output.

Contributor

alindeman commented Sep 18, 2012

What if we started accepting both forms now and deprecated the underscore versions in 3.0? I feel like it might be annoying to rip them out at this point, even in a major version bump. Or am I being too sensitive?

Owner

dchelimsky commented Sep 18, 2012

@alindeman the trick is to support both versions as input, but only display the dashed versions in the output of rspec --help.

Contributor

alindeman commented Sep 18, 2012

I think the right thing to do is either only support dashes on the command line or figure out a way to support input of dashes or underscores but only display options with dashes in the optparse output.

Righto. I missed this comment in the other emails from today.

I will dig around optparse a bit later, unless someone knows how to do this off-hand?

Contributor

alindeman commented Sep 19, 2012

I attempted to poke around optparse.rb, but failed miserably at understanding if it had any way to add "undocumented" options.

What if we instead changed our optparse code to expect --line-number and --default-path and transformed any --line_number or --default_path options into the dashed version before they were parsed? (we already do something similar with --formatter)

Owner

dchelimsky commented Sep 19, 2012

I forgot about that :) That sounds fine, though we don't need to provide deprecation warnings for these IMO.

@ghost ghost assigned alindeman Sep 25, 2012

@alindeman alindeman closed this in ef74478 Sep 26, 2012

@alindeman alindeman added a commit that referenced this issue Sep 26, 2012

@alindeman alindeman Changelog for #497, #691 [ci skip] 92038d3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment