Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project basename creation #24

Open
Eneroth3 opened this issue Jan 14, 2018 · 4 comments
Open

Project basename creation #24

Eneroth3 opened this issue Jan 14, 2018 · 4 comments

Comments

@Eneroth3
Copy link
Contributor

I've noticed the namespace "Eneroth::SkippyTest" generates the basename "En_SkippyTest".

I would expect the name to be in snake cases, e.g. "en_skippy_test", as specified by bbatsov's style guide.

I've also started to think about the two character vendor prefix. When the developer community grows, isn't there a risk people's initials/abbreviations soon starts to collide? Is there any particular reason for not writing out the full name, e.g. "eneroth_skippy_test"? Perhaps the full namespace name could be used when just one initial can be found in it, and otherwise the initials?

@thomthom
Copy link
Owner

If you do skippy new Eneroth::SkippyTest -d (or --downcase) it will become en_skippytest. (It is possible to adjust the file-namespace in skippy.json afterwards.

Right now the rules for how these names are generates are more or less randomly picked. Something to be refined, along with more options to rename etc.

@Eneroth3
Copy link
Contributor Author

-d isn't ideal as it still doesn't split SkippyTest into skippy_test. However the -b (--basename) can be used to achieve the desired result.

I can understand if this isn't the highest priority. Do you mind if I attempt to tweak basename generation and make a pull request?

Btw, the ability to easily replace the basename, as well as other project properties, is very much appreciated! Trying what happens if you edit skippy.json was one of the first things I did. This transparency, in contrast to somehow relying on a non-human-readable database or internal variables, makes it very easy as a user to understand what Skippy is doing and makes it very comfortable to work with!

@thomthom
Copy link
Owner

I'll have more time to respond once I'm back om the US. I've hardly been at my computer for the last two weeks.

I think I want to get rid of the two separate -d and -b options and instead replace them with a single option that accept various formatting style descriptions:

camelCase, CamelCase, under_score etc... or something to represent that.

But before that skippy needs a way to store application preferences. This is also needed to persists defaults when creating new projects, as well as installing templates.

I just tried to build skippy on a new machine, and I ran into some errors. I need to fix that before anything. Otherwise tests won't run.

@Eneroth3
Copy link
Contributor Author

Poor computer :O :'( .

I'm thinking just one parameter for setting a completely custom basename is best.

Regarding options for formatting styles I think it's better to always format according to Ruby guidelines (snake case only) as that would cover 97% of use cases, In the other cases the user could manually enter the basename.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants