STYLE: Change template parameter name prefix N to V

[Leengit]

Template parameters that are of typename have names that start with T, but for template parameters that are values (e.g., unsigned int) rather than types, both N and V have been used as a prefix for their names. This pull request changes instances with prefix N to have a V prefix. Additionally NDimensions (plural) is changed to VDimension (singular).

Note that class members (typically static const(expr) members) are sometimes named with an N or V prefix. Perhaps neither of these prefixes is appropriate by the ITK Style Guide. Nonetheless, these are not changed because outside code, such as ITK modules, might refer to them by their current names.

Thanks to @N-Dekker for discovering this issue.

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)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

[N-Dekker]

Great job @Leengit 👍 Thanks for addressing the issue that I raised at discussion topic Which initial is preferred for a non-type template parameter, N or V (NDimension or VDimension)?

Do you think we should then also adjust Utilities/KWStyle/ITK.kws.xml? I don't really know how that works, but the xml code <Template>([TNV]... seems to allow both N and V.

Some minor comments regarding your commit messages:

BUG: Revert b04d9cd for member variables.

I'm not sure if that particular SHA (b04d9cd) will make it onto the master branch. During rebase/merge, the SHA of the commit may change. It's probably more safe to just say something like:

BUG: Revert changes from previous commit for member variables

But I guess you might as well squash both commits to one, if that's OK to you.

I noticed that you add a period ('.') to the subject line of commit messages. Is that really helpful to you? Because it seems a bit odd to me. A large majority of commit messages certainly don't have that period. And it does not seem necessary to me, because it is just the subject, not necessarily a complete English sentence. And as the number of characters preferred for a subject line is limited (maximum 72 character), I wouldn't want to start adding periods to my subject lines!

[Leengit]

Thank you @N-Dekker for the suggestions. With this force-push, I have merged the commits, removed the SHA code and trailing period from the commit message, and removed N from Utilities/KWStyle/ITK.kws.xml.

[dzenanz]

Looks good on a glance. There were also quite some manual interventions here!

[Leengit]

I'd like to see how this does with overnight testing runs because it touches a lot of files. If all remains green then this should be good to merge.

[N-Dekker]

Approved, even though personally I would have preferred consistent use of the N, rather than the V as prefix for non-type template parameters.

[thewtex]

Please rebase and add the commit to .git-blame-ignore-revs.

[Leengit]

Rebased. Will add to .git-blame-ignore-revs after merging.

[Leengit]

This passed all its tests. I have squashed, rebased to current master, and force-pushed. This is ready for merging.

[kwrobot-v1]

Errors:

• Failed to reserve ref 123fa9d for the merge request: invalid git ref: 'no such commit'.
• Failed to run the checks: mr utilities error: failed to list commits of 123fa9dfcd327998ecf75dc0b52c4dbe090178e0 for https://github.com/InsightSoftwareConsortium/ITK/pull/3171: fatal: bad object 123fa9dfcd327998ecf75dc0b52c4dbe090178e0 .

[Leengit]

I rebased against the newly current master and force-pushed. The strange message from kwrobot-v1 makes it seem like my force-push collided with a merge attempt by someone else. If that's what is going on, attempting the merge again might be the right course of action. If not, please help me to understand the message from kwrobot-v1.

[dzenanz]

The KWRobot message came 1 second after my approval, so I think that is what caused it. Your PR is not merged.

[Leengit]

The KWRobot message came 1 second after my approval, so I think that is what caused it. Your PR is not merged.

Probably then my force-push collided with your approval; perhaps KWRobot was trying to say that you were approving a commit that had been obsoleted in the seconds before-hand.

Perhaps extra caution is appropriate nonetheless. We might wait for the checks to pass (again) before merging.

[dzenanz]

Your force-push was 5 minutes before my approval. So no, I can't imagine those two colliding.

[Leengit]

There was a second force push.

[dzenanz]

Than that was probably it. I now see that force-push, but I didn't see it when I wrote #3171 (comment).

[Leengit]

Because one of the checks was stalled for several days, I just took the opportunity to rebase to the current master branch and force push. There are no other changes.

[dzenanz]

This is probably what broke FEM module. It is off by default. I have it enabled locally, for testing. I now run into:

96>------ Build started: Project: ITKFEMRegistration, Configuration: Debug x64 ------
96>itkFEMRegistrationFilter.cxx
96>C:\Dev\ITK-git\Modules\Numerics\FEM\include\itkImageToRectilinearFEMObjectFilter.h(72,54): error C2065: 'VDimension': undeclared identifier
96>C:\Dev\ITK-git\Modules\Numerics\FEM\include\itkImageToRectilinearFEMObjectFilter.h(175): message : see reference to class template instantiation 'itk::fem::ImageToRectilinearFEMObjectFilter<TInputImage>' being compiled
96>C:\Dev\ITK-git\Modules\Numerics\FEM\include\itkImageToRectilinearFEMObjectFilter.h(72,1): error C2975: 'VDimension': invalid template argument for 'itk::fem::FEMObject', expected compile-time constant expression
96>C:\Dev\ITK-git\Modules\Numerics\FEM\include\itkFEMObject.h(74): message : see declaration of 'VDimension'
95>ITKIOHDF5.vcxproj -> C:\Dev\ITK-vs19\lib\Debug\ITKIOHDF5-5.3.lib
96>Done building project "ITKFEMRegistration.vcxproj" -- FAILED.

[dzenanz]

Definition of this on line 60 was not updated.

[dzenanz]

Addressed in #3201.