A tale of code

Take a look at this:

Mr. Enfield returned: "But I happen to have noticed his address; 

                      he lives in some square or other".

"And you never asked about the—place with the door?" 

Mr. Enfield's reply was:  "No, sir; 

                          I had a delicacy. 

                          I feel very strongly about putting questions; 

                          it partakes too much of the style of the day of judgment. 

                          You start a question, and it’s like starting a stone. 

                          No sir, I make it a rule of mine: 

                            - the more it looks like Queer Street, the less I ask".

The lawyer said: "A very good rule, too".

Mr. Enfield continued: "But I have studied the place for myself".

The pair walked on again for a while in silence and then: "Enfield... 

                                                           That’s a good rule of yours." 

And this one

Mr. Enfield returned: 

  "But I happen to have noticed his address; 

  he lives in some square or other."

"And you never asked about the—place with the door?"  

Mr. Enfield's reply was:

  "No, sir; 

  I had a delicacy. 

  I feel very strongly about putting questions; 

  it partakes too much of the style of the day of judgment. 

  You start a question, and it’s like starting a stone. 

  No sir, I make it a rule of mine: 

    - the more it looks like Queer Street, the less I ask."

The lawyer said: "A very good rule, too". 

Mr. Enfield continued: "But I have studied the place for myself". 

The pair walked on again for a while in silence and then: 

  "Enfield... 

  That’s a good rule of yours."

This one:

vs this one:

The flow:

and

Now with code. Don’t focus on code semantics, but the visual representation.

The first examples, following Clean ABAP preferred rules:

and with helper variables:

Now applying refactoring –  Alt+Shift+R in Eclipse, some names changed:

the second with helper variables:

Different style examples with incremental indentation:

with helper variables:

Applying refactoring, names changed:

and the second version refactored:

The last two images shows why I personally prefer using incremental indentation – no messed up code after renaming. Both styles are readable for me but this the second one without so strict alignment is refactoring-friendly, which is a very important thing for constant improvement of code and naming things correctly. I don’t want to manually correct main code + unit test code + dependent code after each name change (and be sure that everyone in a team remember to “fix” code after his or her refactoring changes). This heavily right-aligned code is also hard to read on smaller screens in editors or webpages like version control systems.

Speaking of version control – here are diffs for the Clean ABAP preferred rule, after refactoring I have aligned all things again.

◉ ABAP Git diff (where are my name changes?):

◉ Bitbucket diff:

Now incrementally indented code – changes are visible clearly.

◉ ABAP Git diff

◉ Bitbucket diff:

Interesting video about this topic by Kevlin Henney (starting around 10-11 minute).

The key point from this presentation to me is that keeping the codebase stable after rather trivial refactoring operation is not conforming to a style, but rather to an invariant, a property.