Submitting code clean-up (moodlecheck, codechecker)

Submitting code clean-up (moodlecheck, codechecker)

by Dave Balch -
Number of replies: 4

CiBot told me that pull branches I've added to MDL-46116 have (pre-existing) documentation and Moodle coding guidelines issues.

Assuming I can find time to tidy, what's the recommended approach for submitting fixes to these problems (as reported by the moodlecheck and codechecker plugins)?

  1. Tracker issue specifically for the module being tidied.
  2. As a separate commit in the same issue.
  3. Something else?


Average of ratings: -
In reply to Dave Balch

Re: Submitting code clean-up (moodlecheck, codechecker)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Probably 2.

There are occasions where 1. might be more appopriate, but normally it is not worth it.

Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Submitting code clean-up (moodlecheck, codechecker)

by Dave Balch -

Cool, thanks Tim.

In reply to Dave Balch

Re: Submitting code clean-up (moodlecheck, codechecker)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I suppose we should make it clear:

The one thing you should not do is mix up irrelevant coding style clean-up with a real functional change as part of the same commit. The extra noise in the patch make it harder to understand the change.

You obviously know this, since you did not even suggest doing that, but I thought it helpful to make it clear as part of this thread the one things you really should not do.

In reply to Dave Balch

Re: Submitting code clean-up (moodlecheck, codechecker)

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Just for reference, there is this policy issue about that: MDL-43233

In general, I agree that separated is better, different commits in the same issue - fix and (related) coding style. Or completely separated issues for coding style unrelated/only changes. That seems to be the trend from the opinions in that policy issue.

Ciao smile
Average of ratings: Useful (1)