ENH: Add C++ script to add in-class {} member initializers to ITK

[N-Dekker]

The script that was used for the following pull requests:

• pull request STYLE: Add in-class {} member initializers to objects created by New() #3851
• pull request STYLE: Add in-class {} initializers to classes with virtual functions #3913
• pull request STYLE: Add in-class {} initializers to classes with override = default #3917
• pull request STYLE: Add in-class {} member initializers to 3-letter data members #3941
• pull request STYLE: Add in-class {} member initializers having trailing comments #3945

[dzenanz]

Woo-hoo, CI was not run.

[jhlegarreta]

Thanks for doing this @N-Dekker 💯, and also all the related PRs lately, and the PR to skip the CI for files that do no need to be tested.

[N-Dekker]

You're welcome @jhlegarreta I'm happy to see that it did not trigger a CI run 😃

You know I hesitated to place this script in the ITK git repository, because I did not want to add an extra maintenance burden. The script was meant to reduce maintenance in the first place! Once it is in here, people may do code clean-up's, fix typo's, upgrade the code to newer style guidelines or other compilers, etc. While I think ITK has more than enough code to maintain already!

As a compromise, could we agree that this script does not need to be at the master branch "forever"? Could it possibly be removed from the master after the next major release or so?

By the way, I may still make some small adjustments to the code, that's why it's still draft now.

[jhlegarreta]

You know I hesitated to place this script in the ITK git repository, because I did not want to add an extra maintenance burden. The script was meant to reduce maintenance in the first place! Once it is in here, people may do code clean-up's, fix typo's, upgrade the code to newer style guidelines or other compilers, etc. While I think ITK has more than enough code to maintain already!

As a compromise, could we agree that this script does not need to be at the master branch "forever"? Could it possibly be removed from the master after the next major release or so?

Niels, we ourselves are trying to maintain code that we did not write, so anybody in the open source community that is interested in ITK is more than welcome to improve the script if they need it. But in the first place, it can be very useful for e.g. remote modules.

So even if you cannot devote time to maintain it further, I would keep it; it does not make sense to me to remove it for the next releases (for example, not all remotes may have time to apply the script by then).

By the way, I may still make some small adjustments to the code, that's why it's still draft now.

Fine, I just wanted to thank you for the effort of doing these things.

[blowekamp]

Is there much overlap with this an the "use-default-member-init" functionality of clang tidy?
https://clang.llvm.org/extra/clang-tidy/checks/modernize/use-default-member-init.html

@N-Dekker Can you compare and contrast functionality?

[dzenanz]

If we remove these scripts from master, they would be even harder to find than they are now. I vote to keep them where they are. We might even consider moving Maintenance folder to repository root, for improved visibility.

[N-Dekker]

Is there much overlap with this an the "use-default-member-init" functionality of clang tidy?

Thanks for asking @blowekamp I think this script (AddEmptyDefaultMemberInitializers.cxx) is complementary to the clang tidy "use-default-member-init" option. The clang-tidy option moves existing (C++98/03 style) member initializers from constructors to the corresponding C++11/C++14 in-class data member declaration. While the script adds in-class {} initializers to data member declarations that did not yet have them.

Note that Hans (@hjmjohnson) has already run the clang tidy option extensively:

• PR STYLE: Prefer default constructors #3162 commit ac4c234
• PR STYLE: Use default member initialization #2305 commit 8751ef7
• PR STYLE: Clang tidy cleanups #1628 commit 18d43c8
• PR STYLE: Use default member initialization #324 commit b21dbbb

[N-Dekker]

FYI Before merging, I would still like to extend the script to address lines of code that do not end with a semi-colon! Specifically:

int m_Data; // Some comment

Because of the trailing comment, this data member is still ignored now, even if it should have a {} initializer. To be continued... 😃

[thewtex]

Amazing to see C++ capable of what effectively only scripting languages could do in the past! 🎇