DOC: Adjust initialization rule for padding data, smart pointers, etc.

[N-Dekker]

Excluded padding data, std::unique_ptr, itk::SmartPointer and low level
utility classes from the guideline that says that "all member variables must be
initialized when they are declared".

std::unique_ptr and itk::SmartPointer are excluded because of some GCC
compile errors, which were addressed in ITK by Simon Rit (@SimonRit):

• pull request COMP: Remove in-class {} member initializers of unique_ptr ITK#3877
  commit InsightSoftwareConsortium/ITK@eac289d
  "COMP: Remove in-class {} member initializers of unique_ptr"
• pull request COMP: Remove in class init of SmartPointer of forward declaration ITK#3927
  commit InsightSoftwareConsortium/ITK@f5f8367
  "COMP: Remove in class init of SmartPointer of forward declaration"

[N-Dekker]

Looks like the following part is incorrect, and should be removed, right?

ITKSoftwareGuide/SoftwareGuide/Latex/Appendices/CodingStyleGuide.tex

Lines 1624 to 1635 in 905c9bb

	Nevertheless, there may be some exceptions to the initialization list rule. In
	some situations where it can be foreseen that the corresponding
	\code{Set\#\#name} or \code{\#\#nameOn}/\code{\#\#nameOff} may be
	\begin{itemize}
	\item overloaded by some classes in the future, or
	\item deprecated, and a warning thrown when it is called to help migration,
	\end{itemize}
	initialization through the corresponding \code{Set\#\#name} or
	\code{\#\#nameOn}/\code{\#\#nameOff} method is recommended instead of directly
	manipulating the data member.

Even when a constructor would call Set##name for some of its data members, it should still "directly manipulate" those data member as well, by initializing each of them before calling the Set member function. As @jhlegarreta proposes with InsightSoftwareConsortium/ITK#3845

[jhlegarreta]

Sorry for the delay.

initialization through the corresponding \code{Set##name} or
\code{##nameOn}/\code{##nameOff} method is recommended instead of directly
manipulating the data member.

Yes, not sure which were the reasons for this. There were probably some that were discussed in a PR when some issue was discovered.

Even when a constructor would call Set##name for some of its data members, it should still "directly manipulate" those data member as well, by initializing each of them before calling the Set member function. As @jhlegarreta proposes with InsightSoftwareConsortium/ITK#3845

As surfaced by InsightSoftwareConsortium/ITK#3845 (comment), there maybe (especialized/exceptional) cases where grouping some initializations may be wise: e.g. in cases where a group of variables may be (re-)initialized by calling an Initialize-like method (regardless of whether the method is private/protected/public). So I am unsure of how we should put this.

[N-Dekker]

Not really sure how to continue with this PR now. First of all, it has a build error. Any suggestion how to fix it?

Secondly, shall I basically keep it as it is now? Or further extend it to include a new paragraph about data members of a smart pointer type? And then, shall I remove the old section about Set##name, as it appears incorrect. Or postpone such adjustments to a possible future PR?

I'm asking especially because it appears hard for me to get PRs merged into ITKSoftwareGuide, either because of build errors or ongoing discussions.

[jhlegarreta]

Retriggering the build may fix the failures; successful builds also report warnings similar to those reported until the build was stopped:
https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide/actions/runs/3543105257/jobs/5949264193#step:5:42746

As for going forward, Dženan has approved so if he/others are comfortable with the edition, then I do not want my comments to prevent this from being merged.

[jhlegarreta]

🤷 No idea why the build fails. Do not see any cue in the logs.

[jhlegarreta]

🤷 No idea why the build fails. Do not see any cue in the logs.

Maybe this has to do with it: the line needs to be wrapped at 79 chars, and the proposed addition has a line length of 99 or 100.

[N-Dekker]

GitHub says:

N-Dekker dismissed stale reviews from tbirdso and dzenanz via 992149c

This sounds so rude, and it just isn't true! I did not dismiss anybody's review, I just did another force-push, as another unfortunate attempt to make the CI happy!

[thewtex]

LGTM

[dzenanz]

Dismissing stale reviews is not rude, it is rather normal. At least in my opinion.

[thewtex]

@N-Dekker Could you please rebase on master to see if we can get a clean build?

[SimonRit]

Thanks for documenting this!