refactor: ensure correct usage of underscores and hyphens for file and folder names

[bobleesj]

Double check that we use "-" for folders, static files (.rst). Please check the tutorial provided in scikit-package/scikit-package#330

[sbillinge]

@TingwenZhang will take this issue

[sbillinge]

@TingwenZhang that's great! Please reach out if you have quetions.

[cadenmyers13]

@TingwenZhang please let me know if you need help by leaving a comment here. Thanks!

[sbillinge]

@TingwenZhang please respond to comments, even it is just a thumbs up emoji, so we now you have seen it.

[TingwenZhang]

@sbillinge @cadenmyers13
I realized that the issue is not so much of - vs. _, but of all hundreds of filenames being mere concatenation of strings (e.g. structureviewer.py, adddatapanel.py).

Is there a reason that the author made use of neither camelCases nor snake_cases?

Should pdfguimacros.py be pdf_gui_macros.py or pdfgui_macros.py? Either way, how should we name pdfcomponent.py , with no contradiction on the split of pdf?

I have done a few dozens of re-namings but ran into the contradictions above. Is there a standard the author wants for these python files? Because renaming the few hundred files also involve renaming all references to the re-named files within the files.

[sbillinge]

Thanks @TingwenZhang this is a great point. we don't really have a group standard on this. For the purposes of this task, let's just keep it to the consistent use of _ and -. We could create an issue to revisit some other renamings of contatenated filenames. We could also maybe formulate a group standard on that. The general goal is to make module names both easy to read and easy to type as well as compliant with pep8. Underscores tend to add to the typing overload so I am not totally opposed to simple concatenation. We never use camel case for module names (violates PEP8) except in some very special situations.

[TingwenZhang]

@cadenmyers13 @sbillinge
Could you check what is that workflow error on my pull request? https://github.com/diffpy/diffpy.pdfgui/pulls

[sbillinge]

btw, small point but this is probably a chore: not a feat:. feat: indicates new functionality for the user. I am not sure if this came from @bobleesj or where, but just sayin'

[TingwenZhang]

Yes, after double checking the standard, this change should be a chore.

[TingwenZhang]

For diffpy/diffpy.snmf, the only issues are
./examples/mix___ZnSe-w_0.5___BaTiO3_c-w_0.5
./examples/mix___ZnSe-w_0.5___BaTiO3_c-w_0.5/ZnSe-w_0.5___BaTiO3_c-w_0.5-15.gr
./examples/mix___ZnSe-w_0.5___BaTiO3_c-w_0.5/ZnSe-w_0.5___BaTiO3_c-w_0.5-10.gr
...

However, these special filenames may be intended by the author. My opinion is to not touch these filenames.

I think no change is needed in https://github.com/diffpy/diffpy.snmf.

[sbillinge]

This is a good suggestion.

However, @TingwenZhang here I would fix them but work with @john-halloran and come up with a better naming scheme overall. These long filenames are left over from a project they are taken from, but if we are going to use them as examples in the snmf code we would like them to exemplify good naming conventions, both in terms of dashes, but also just generally be more readable? We could maybe have a conversation here about how that could look. For example, I see a lot of repetition between the folder name and the filename. If this is the only example, then calling the folder mix-ZnSe-BaTiO3 might make more sense, but I don't see all the files. Anyway, I think it is worth cleaning these since we are using them as examples.