DOC: Avoid documenting ivar default values in SpatialFunction class

[jhlegarreta]

Avoid documenting ivar default values in
itk::ConicShellInteriorExteriorSpatialFunction since:

• All ivar values should be initialized to some default value.
• When default values are changed, it is easy to forget about updating the documentation and making it inconsistent with the actual value in the code.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Updated API documentation (or API not changed)

[jhlegarreta]

Not sure there is another way to show ivar default values through the Doxygen documentation, but I do think that we should avoid documenting explicitly for the above reasons.

Cross-referencing: InsightSoftwareConsortium/ITKSoftwareGuide#202

[N-Dekker]

Well... in general there is always redundancy between documentation and implementation. And one may accidentally forget to keep the documentation consistent with the implementation. But in this particular case, the initialization is itself already included with the doxygen output at https://itk.org/Doxygen/html/classitk_1_1ConicShellInteriorExteriorSpatialFunction.html#aa0bf34461e6adf408abc7a0bf6e995c5 as it says:

bool [...] m_Polarity { false }

So end users can find the default initial value of Polarity from the documentation this way.

Thanks Jon! 👍

[jhlegarreta]

Ah, thanks @N-Dekker, I had a quick look yesterday before adding the GitHub message and looks like I completely missed it.

[jhlegarreta]

Looks like the badges in the README and the Azure build status are not in sync. Not sure why. Badges are all green

but Azure builds are not

Also, badges are pointing at different commits across builds, e.g. f602b3c1 for ITK.Windows, 3c20912e for ITK.macOS.

@thewtex @tbirdso would you be able to investigate this, please? Thanks.