refactoringcombos / arloscommitnotation Goto Github PK

Example:

> p4 submit -d "R!! inline method"

This will expand to

> p4 submit -d "Rmylastcommand inline method"

or something.

I guess I need to learn to use single quotes to use this.

I tried this and my reviewer gave this feedback.

Also: "i really don't want to have to go to a legend to see what these mean"

I get that this notation can be learned but wanted to pass along the feedback.

Why does R require:

You followed the published recipe, including running full-suite test runs when indicated.

?

Wouldn't a recipe give you r?

Hello,

Love this so far! But what is the definition for LoC? Is this "line of code"? I think so, but it's not too common of an acronym (I didn't know at first). Would love to have it in the documentation. Let me know if you need someone else to make a PR.

Thanks!

Turning on a new lint rule / enabling a warning + warn-as-error / enabling more static analysis - these are in the low-risk category.

Should this be grouped into e?

It is possible to use tests to eliminate even unknown risks in some cases.

For example, TeamCity's Kotlin DSL is a program that takes 0 inputs, consistently producing the same outputs (some XML files) each time it is run. Golden Master / Approval Testing the generated XML is sufficient to guarantee that a refactoring did not change anything: if the generated XML is unchanged, the program is unchanged.

When we say to use R for Test-supported refactoring, we assume that the test coverage is incomplete, but in the above example the test coverage is complete.

This is an even higher level of proof than we get with almost all automated refactoring tools.

We currently use three spaces for safer commits (r Extract Method) so that they align well with unsafe commits (R!! Cleaned up the core logic) but that only works with fixed-width display. Many UIs merge those spaces, like this in GitHub:

Typically in my red/green/refactor cycle I'll write a test, see it fail, make it pass, and then commit with F or F!! or B or B!!. If I have named my new test well, it will be the commit title.

Sometimes I want to make it obvious that I wrote a failing test before making it pass, so I want to commit the new test by itself.

I wonder if T** would be a good prefix for this situation? Maybe f / b would be a good followup to a T**?

I recently presented ACN to an audience that wasn't already fluent in disciplined refactoring, and got resistance of the form "why should I shift how I work and how I think about development + learn this new notation? What's in it for me?"

That may deserve its own article, but perhaps we can identify something pithy to add here.

I started working in this way because it made my life easier: it was easier to make my code changes, to understand what changes I had made, and to roll back when something went wrong.

When trying to understand whether some weirdness in legacy code was deliberate, I find where it was added in commit history. When fixing a bug, I search history to understand whether I am actually undoing a bug fix that I don't understand. Both of these are aided by the incrementality that ACN invites and by the expressions of intent and risk.

When I've tried to explain that last paragraph to people, sometimes they get it immediately, and sometimes they are surprised at the idea that reading commit history could be useful.

What would you add to the list? See anything that could be a pithy soundbite?

In GitLab under Settings -> Repository -> Push Rules you can set Require expression in commit messages. I assume GitHub has a similar feature.

A regex for ACN would need to be permissive enough to allow local extensions but require the extension.

Here's the regex I'm currently using: ^(([[:lower:]] )|([[:upper:]] )|([[:upper:]]!! )|([[:upper:]]\*\* ))|(\*\*\*).

When we add this guidance we could use CI to test it. Here are some test cases + questions:

For some audiences, this is a problem.