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 coding standards #287

Open
HaleTom opened this issue Mar 5, 2019 · 3 comments
Open

Project coding standards #287

HaleTom opened this issue Mar 5, 2019 · 3 comments

Comments

@HaleTom
Copy link
Collaborator

HaleTom commented Mar 5, 2019

Dear fellow maintainers,

You may remember me as the guy who dropped a significant PR a few months ago.

After fixing many quoting issues, I saw someone (I believe it was the original author, but could be wrong) making some commits with introduced another one or two of the same class of bug that I'd just spend a long time fixing.

(Please always quote $@ unless you have an explicit reason not to, including the non-usage of arrays.)

I was thoroughly discouraged, and haven't contributed since (saving issues directly related to the code that I contributed.)

So, I'd like to raise an observation, and make a proposal.

My observation (right or wrong, please correct me) is that this project seems to have started as a convenience script, and the original author adds things without a code review process.

This code base seems to have new features added to do nifty timesaving tricks, but lacks an emphasis on correctness and robustness, prioritises features over quality, and lacks edge- and corner-case tests.

sh and its derivatives are arguably poorly designed languages and edge case foot-shooting is common.

I propose:

  1. To catch bugs, that this project be shellcheck clean.

    Yes, sometimes shellcheck is annoying and gets it wrong. But it forces coders (via an ignore directive) to explicitly say "yes, I've read the cautions and really do know what I'm doing".... or (more commonly) to say: "damn, that's an edge case" and fix what will likely result in unexpected behaviour down the track.

  2. That there be a review process for contributed code.

@jeffbyrnes
Copy link
Contributor

@HaleTom I’m a big fan of spellcheck, and I’d be on board with adhering to it, with specific carveouts being exactly that: clearly commented, per-exception carveouts (which I think it allows? I’m assuming that based on the behavior of other linters).

jeffbyrnes added a commit to jeffbyrnes/scm_breeze that referenced this issue Mar 12, 2019
jeffbyrnes added a commit to jeffbyrnes/scm_breeze that referenced this issue Mar 12, 2019
@HaleTom
Copy link
Collaborator Author

HaleTom commented Mar 13, 2019

@jeffbyrnes Great work on #288 w.r.t suggestion (1).

Yes, "Shaddup, I know what I'm doing" is definitely supported by shellcheck. :)

I would appreciate thoughts on suggestion (2) from anyone.

@ndbroadbent
Copy link
Member

Hi @HaleTom, I’m really sorry that I introduced those bugs! Sorry, I just saw this issue now. (I stopped watching the repo and turned off notifications since I got a bit burned out from responding to issues.)

I’ll definitely stop pushing any more code directly to master, and will open a PR next time to get some feedback first. (Although I’m not planning to work on any more changes.)

shellcheck sounds like an awesome idea, and that will be great to add to the CI build.

Sorry again, that won’t happen again! And thanks a lot for contributing those fixes!

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