Changes in "padding" on blank VBA code lines

[joyfullservice]

On the topic of sanitizing source files, there are a couple outstanding issues on the VBA side that frequently cause unwanted "noise" when committing changes to version control systems. While the role of this add-in is not to change the VBA code, (we want to leave that responsibility to the developer) we do want to produce a consistent output at the source file level, especially in areas where the IDE introduces low-visibility changes that are not always noticed by the developer.

Let me give an example to illustrate this behavior:

Write a classic snippet of code in the IDE:

Public Sub Hello()
    MsgBox "Hello, World!"
End Sub

Now, place your cursor at the end of the line, and press enter... The IDE will helpfully automatically indent you to the same level as the previous line. (I do like that feature.) You are now ready to start typing the next line of code.

But what if you simply intend that line to be a space between some sections of code? The space looks great until you load this into version control, and find a mix of padding and blank lines that sometimes changes unexpectedly.

For example, if you comment out this entire block, then uncomment it, the padding disappears.

That missing padding now shows up as a "change" in version control.

What I am proposing is that if the sanitize level is set to aggressive (default) or higher, this padding would be automatically removed in the source files. (The same effect as if you selected all the code in the module, and toggled the block comment on and back off.) This would reduce the "noise" I sometimes see in projects where nothing actually changed in the source code, but the padding on blank lines was added or removed. (You cannot add trailing spaces on code lines anyway, so this only affects blank lines.)

A second related proposal here would be to standardize all code modules on export to have a single blank line at the end of the code. (This is standard practice in many programming languages, and would just help enforce a consistent output in the source files.)

I should note that neither of these changes directly modifies the existing VBA code in the project. It only affects what is saved in the export files. (This would, of course, but reflected in the VBA project after building or merging from source.)

This is not an attempt to "prettify" the source code (which would be outside the purpose of this add-in) but simply a way to manage the varied whitespace changes triggered by the IDE so that we can maintain consistency in the source files.

Any thoughts?

[mwolfe02]

I'm on board with both of those changes.

[joyfullservice]

This has been implemented, and I am loving the consistent output! 😄 There will be some "noise" on the first export as all the existing whitespace gets cleaned up, but after that first export, this should be a non-issue going forward.

Note that I did not address the blank lines at the end of form and report code modules, since that export process is likely to change when we split the code modules from the layout definitions.

[bclothier]

One caveat to check is whether this affects how files are imported. I remember long time ago there was a discussion among Rubberduck team where importing a file with a newline at end causes it to be imported as a class module. Mind, that may be using VBIDE API to import, rather than Access' LoadFromText, so there may be a difference in the behavior.

[joyfullservice]

@bclothier - Thanks for the heads up on that. Modules are loaded through VBE (to preserve hidden attributes) but I have never seen an issue with any of the projects I have worked with. I did a full round trip export and build from source on the add-in, which includes both modules and classes, and everything imported correctly. Definitely open an issue if you encounter any problems with module imports.