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

Agree on shell code styling #28

Open
smaddock opened this issue Feb 18, 2022 · 7 comments
Open

Agree on shell code styling #28

smaddock opened this issue Feb 18, 2022 · 7 comments

Comments

@smaddock
Copy link
Collaborator

I've been building a loose “style guide” for BlueSkyConnect shell scripts. I've been documenting it in a .editorconfig and you can see the changes in the main branch of my fork.

Some additional changes I want to make right away:

  • consistent variable name casing ($camelCase vs $SNAKE_CASE)
  • replacing the SolarWinds reverse DNS with something like net.blueskytools.connect
  • consistent formatting on the inline MySQL

There should be no functional changes, just formatting, documentation, bug fixes, small optimizations, and very minor restructuring — but with 1200 lines and counting changed, it will definitely require testing.

If these kind of linting changes are of interest and people agree with my style choices, I can submit a PR, but I also know reviewing big PRs is a time suck, so it might be easier to start like a 2.4alpha branch or something. Whatever the community is interested in.

@sphen13
Copy link
Collaborator

sphen13 commented Feb 18, 2022

all sounds good to me - i would say there is a ton to review here. We could just create a dev or wip branch for commits we want against the next version. i would like to keep master/main down to latest release. when we are good with say the dev branch and ready to release we will PR to main and create a tag for the release.

@smaddock
Copy link
Collaborator Author

If you create the dev branch I’ll submit a PR against it when I have this at a good point. Maybe dev-2.x? To leave room for a future dev-3.x.

@smaddock
Copy link
Collaborator Author

Also definitely want @AllPurposeBen’s input on the styling choices.

@sphen13
Copy link
Collaborator

sphen13 commented Feb 18, 2022

done - dont get ahead of yourself with 3! :)

@AllPurposeBen
Copy link
Collaborator

AllPurposeBen commented Feb 18, 2022

I'm good with whatever standardization as long as it's documented for ref and/or editor config'd. else I'll forget.

Definitely a testing branch. I'd love to be able to unitary test via docker so if we can document how a dockerfile for getting from a branch to a working testing env, that would help with consistency, for me at least.

I've got stock testing VMs back to 10.11 for client testing, wasn't planning on going older than that. I'd even feel ok bumping the "we tested this X far back, YMMV" floor up to like 10.14.

@smaddock
Copy link
Collaborator Author

I think I have my shellFormatting branch at a good point to consider merging into the dev-2.x branch. I didn't change the reverse DNS since that could be a breaking change.

Since there are no functional differences I don't think it's worth a release, but I think it is a better point to move forward with actual modifications.

I still need to test it to make sure I didn't bork anything obvious and then I'll submit a PR.

@smaddock
Copy link
Collaborator Author

smaddock commented Mar 8, 2022

I have the first few rounds of code cleanup ready, but I think it'd be easier to wait until existing PRs are committed so we don't have merge conflicts.

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

No branches or pull requests

3 participants