src/main/java/com/github/_1c_syntax/bsl/languageserver/hover/PlatformMemberHoverBuilder.java (1)

189-196: ⚡ Quick win

Consider extracting the duplicated optional parameter formatting logic.

The optional parameter rendering logic (lines 189-196) is identical to lines 97-105 in ConstructorHoverBuilder. Consider extracting this into a shared utility method to improve maintainability and ensure consistent formatting across both builders.

♻️ Example refactored approach

Create a shared helper method:

private static void appendParameterNameAndType(
  StringBuilder sb, 
  String displayName, 
  String typesLabel, 
  boolean optional) {
  sb.append("- `").append(displayName);
  if (typesLabel.isEmpty()) {
    sb.append(optional ? "?" : "").append('`');
  } else {
    sb.append("`: ").append(typesLabel).append(optional ? "?" : "");
  }
}

Then both builders can call:

appendParameterNameAndType(sb, p.displayName(lang), typesLabel, p.optional());

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/hover/PlatformMemberHoverBuilder.java`
around lines 189 - 196, The duplicated optional-parameter formatting in
PlatformMemberHoverBuilder (around the sb.append block using
p.displayName(lang), renderTypeSet(p.types(), lang), and p.optional()) and the
identical block in ConstructorHoverBuilder should be extracted to a shared
helper to avoid duplication and ensure consistency; add a static utility method
(e.g., appendParameterNameAndType) that accepts a StringBuilder, displayName,
typesLabel, and optional boolean and implements the current conditional logic,
then replace the duplicated code blocks in both PlatformMemberHoverBuilder and
ConstructorHoverBuilder with a single call to that helper.

src/test/java/com/github/_1c_syntax/bsl/languageserver/hover/ConstructorHoverBuilderTest.java (1)

180-196: 💤 Low value

Consider adding test coverage for optional parameter without type.

The test buildRendersOptionalParameterWithDefaultValue verifies optional parameters that have a type (TypeSet.of(NUMBER)). Consider adding a test case for an optional parameter with an empty TypeSet to verify the format `ParamName?` is rendered correctly.

📝 Example test case

`@Test`
void buildRendersOptionalParameterWithoutType() {
  // given
  var param = new ParameterDescriptor(
    BilingualString.of("Опц"), TypeSet.EMPTY, true,
    BilingualString.EMPTY, "");
  var sig = new SignatureDescriptor(List.of(param), TypeSet.EMPTY, "");

  // when
  var content = builder.build("X", STRUCTURE, sig, List.of(sig), false, "");

  // then
  assertThat(content.getValue())
    .contains("`Опц?`")
    .doesNotContain("[optionalParameter]");
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/test/java/com/github/_1c_syntax/bsl/languageserver/hover/ConstructorHoverBuilderTest.java`
around lines 180 - 196, Add a new unit test (e.g.,
buildRendersOptionalParameterWithoutType) alongside
buildRendersOptionalParameterWithDefaultValue that constructs a
ParameterDescriptor with BilingualString.of("Опц"), TypeSet.EMPTY, true,
BilingualString.EMPTY and empty default value, wraps it in a
SignatureDescriptor, calls builder.build("X", STRUCTURE, sig, List.of(sig),
false, ""), and asserts that content.getValue() contains "`Опц?`" and
doesNotContain("[optionalParameter]"); this verifies the
optional-parameter-without-type formatting.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/com/github/_1c_syntax/bsl/languageserver/providers/SignatureHelpProvider.java (1)

537-540: 💤 Low value

Разделитель типов «, » внутри метки параметра неоднозначен.

renderTypes (строки 597‑611) склеивает несколько типов через , , поэтому в метке получается, например, Метод(П: Строка, Число?) — запятая визуально неотличима от разделителя параметров. В hover-карточках (ConstructorHoverBuilder.renderTypeSet) объединение типов рендерится через |. Для единообразия и читаемости стоит использовать | и здесь.

♻️ Возможная правка

   private String renderTypes(TypeSet types, Language lang) {
     if (types == null || types.isEmpty()) {
       return "";
     }
     var sb = new StringBuilder();
     boolean first = true;
     for (var ref : types.refs()) {
       if (!first) {
-        sb.append(", ");
+        sb.append(" | ");
       }
       sb.append(typeService.displayName(ref, lang));
       first = false;
     }
     return sb.toString();
   }

Учтите, что это затронет ожидания существующих тестов signature help.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/github/_1c_syntax/bsl/languageserver/providers/SignatureHelpProvider.java`
around lines 537 - 540, The parameter type separator is ambiguous in signature
labels; update the code so signature help uses " | " between union types instead
of ", ". Modify the call in SignatureHelpProvider (the lines using
renderTypes(p.types(), lang) and label.append) to use a variant that joins types
with " | " (either by adding an overload/parameter to renderTypes or by
introducing a new helper like renderTypesForSignature that calls the existing
rendering logic but uses " | " as the delimiter), and ensure the produced
typesLabel is appended unchanged to the label; adjust tests that expect the old
", " separator accordingly.