Variations on "the boy scout rule" in coding

Many developers talk about versions of the boy scout rule of:

"Try and leave this world a little better than you found it."

Not everyone interprets this the same way and I'm aware of 3 basic variations:

1. Make improvements as part of every change.
2. Leave it (the code) as you'd like to find it.
3. Leave the code a little better than you found it.

Some developers use variation one as an excuse to include their preferences or desires as part of other changes.

Some developers use variation two as an excuse to rewrite the pieces of code they're working on in the way they'd have written it originally.

Some developers think that variation three means that they have to make other changes to a codebase in addition to whatever new feature or bug fix they're working on.

I'm not sure it's any of these interpretations.

This "rule" or "principle" is generally good. Understanding how some people might be manipulating or mis-understanding it can be more helpful.

I like to understand the rule to mean:

"While I'm in this area of the code, are there any important things that also need working on? Or are there any simple fixes I can also address while I'm here?" 

I'll then make those changes as separate commits and/or PRs either immediately before or after whatever task caused me to look at that code.*

I've previously heard this as "code-gardening". It's like the day-to-day removing of "weeds" you notice while doing other things in the garden.

Hmm, there's probably a gender neutral version of this rule we should also consider using instead.

* Side note: I massively improved the work rate at one company when I suggested they switch from randomly assigning changes as part of each release to having all changes related to one area of the code be done by one person and at the same time. This was a very large and very old codebase with a medium-sized team working on it. The change in allocating work removed the majority of merge conflicts and issues from multiple people wanting to work on the same files at the same time. It allowed people to gain a deeper knowledge of some areas of the code, rather than everyone having a superficial knowledge of a lot of it. In turn this meant that solving trickier problems became easier as someone already knew the code well. The change in working allowed developers to take "ownership" of the code they were working on as they'd spent so much time on it and so cared about the quality. And it increased collaboration between developers when they were assigned a new area to work on with the next release. "You, worked on this area for the last release, what do I need to know before I take it over?" Overall, they started shipping faster and with fewer bugs being introduced.

I'm reminded of that change when I hear someone mention the BS rule.