Is your feature request related to a problem? Please describe.
Currently, the hover text for a procedure will automatically add the variable name to the @param text. This causes the variable name to be printed twice if one is following the standard ILEDoc syntax:
///
// My Subprocedure
// @param var1 The first parameter variable
// @param var2 The second parameter variable
///
The hover text for the above will render as:
mySubprocedure(
var1: ind const options(*NOPASS),
var2: ind const options(*NOPASS)
): void
My Subprocedure
@param var1 var1 The first parameter variable
@param var2 var2 The second parameter variable
Notice that the variable names are doubled "var1 var1" and "var2 var2".
This has lead me to start omitting the variable name in the @param doc. This is absolutely the wrong approach. Any changes to the parameter list that are not synced to the @param doc become very difficult to track down and correct.
Describe the solution you'd like
A change to the ILEDoc parser to only prepend the variable name if it is not found (case-insensitive) as the first word of the @param description. This will do the following:
- Encourage proper use of the ILEDoc
@param tag in the syntax of "@param var Description".
- Add visibility of drift between the
@param doc and the procedure definition
- By conditionally prepending only if not found, will maintain backward compatibility
As stated, the change is to the ILEDoc tag parser for the @param tag. It should do a case-insensitive test of the first word of the @param description. If it matches the variable name the parser thinks it should be, then do not prepend. If it does not match, continue with the current logic to pre-pend the variable name.
This conditional pre-pending allow the hover text to be rendered as it currently does for either syntax of the @param ("@param var Description" and "@param Description").
NOTE:
There is one case that will cause the hover text to be rendered differently. If the @param tag does not include the variable name, but the first word of the description happens to match the variable name, the hover text will no longer pre-pend the variable name. For example, assume a procedure has a parameter named quick and that it is documented as // @param Quick access flag. Currently this would be rendered as "@param quick Quick access flag". The conditional pre-pend logic above would find a match between the variable name quick and the @param description's first word Quick. As such, it would render the hover text as "@param Quick access flag".
Describe alternatives you've considered
As mentioned, the alternative is to adopt a @param usage that omits the variable name. This makes the reading of the source difficult and makes reconciling any drift difficult.
Is your feature request related to a problem? Please describe.
Currently, the hover text for a procedure will automatically add the variable name to the
@paramtext. This causes the variable name to be printed twice if one is following the standard ILEDoc syntax:The hover text for the above will render as:
Notice that the variable names are doubled "var1 var1" and "var2 var2".
This has lead me to start omitting the variable name in the
@paramdoc. This is absolutely the wrong approach. Any changes to the parameter list that are not synced to the@paramdoc become very difficult to track down and correct.Describe the solution you'd like
A change to the ILEDoc parser to only prepend the variable name if it is not found (case-insensitive) as the first word of the
@paramdescription. This will do the following:@paramtag in the syntax of "@paramvar Description".@paramdoc and the procedure definitionAs stated, the change is to the ILEDoc tag parser for the
@paramtag. It should do a case-insensitive test of the first word of the@paramdescription. If it matches the variable name the parser thinks it should be, then do not prepend. If it does not match, continue with the current logic to pre-pend the variable name.This conditional pre-pending allow the hover text to be rendered as it currently does for either syntax of the
@param("@paramvar Description" and "@paramDescription").Describe alternatives you've considered
As mentioned, the alternative is to adopt a
@paramusage that omits the variable name. This makes the reading of the source difficult and makes reconciling any drift difficult.