docs: fix internal storage path mentions #55
coding-conventions.yml
on: pull_request
Run style check
19s
Annotations
10 warnings and 5 notices
|
best-practices/literal-named-argument:
src/Web/Blog/BlogController.php#L27
Literal argument `'./index.view.php'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: './index.view.php')` instead of `function_name('./index.view.php')`.
|
|
best-practices/literal-named-argument:
src/Web/Blog/BlogController.php#L21
Literal argument `'/blog'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: '/blog')` instead of `function_name('/blog')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L44
Literal argument `'\\'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: '\\')` instead of `function_name('\\')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L41
Literal argument `'.php'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: '.php')` instead of `function_name('.php')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L40
Literal argument `'https://github.com/tempestphp/tempest-framework/blob/main/'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: 'https://github.com/tempestphp/tempest-framework/blob/main/')` instead of `function_name('https://github.com/tempestphp/tempest-framework/blob/main/')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L39
Literal argument `'/'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: '/')` instead of `function_name('/')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L39
Literal argument `'\\'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: '\\')` instead of `function_name('\\')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L37
Literal argument `'packages/%s/src'` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: 'packages/%s/src')` instead of `function_name('packages/%s/src')`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L37
Literal argument `"/^(\w+)/"` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: "/^(\w+)/")` instead of `function_name("/^(\w+)/")`.
|
|
best-practices/literal-named-argument:
src/Markdown/Symbols/FqcnParser.php#L19
Literal argument `"{(b)?`((?:\\\{1,2}\w+|\w+\\\{1,2})(?:\w+\\\{0,2})+)`}"` should be passed as a named argument for clarity.
Using named arguments for literals, especially booleans, numbers, or `null`, makes the function/method call more self-documenting by clarifying the purpose of the value.
Help: Consider changing the call to `function_name(literal: "{(b)?`((?:\\\{1,2}\w+|\w+\\\{1,2})(?:\w+\\\{0,2})+)`}")` instead of `function_name("{(b)?`((?:\\\{1,2}\w+|\w+\\\{1,2})(?:\w+\\\{0,2})+)`}")`.
|
|
consistency/string-interpolation-braces:
src/Markdown/TempestPackageParser.php#L44
Unbraced variable in string interpolation
Using curly braces around variables in interpolated strings improves readability and prevents potential parsing issues.
Help: Wrap the variable in curly braces, e.g., `{$variable}`.
|
|
consistency/string-interpolation-braces:
src/Markdown/HandleParser.php#L38
Unbraced variable in string interpolation
Using curly braces around variables in interpolated strings improves readability and prevents potential parsing issues.
Help: Wrap the variable in curly braces, e.g., `{$variable}`.
|
|
consistency/string-interpolation-braces:
src/Markdown/HandleParser.php#L37
Unbraced variable in string interpolation
Using curly braces around variables in interpolated strings improves readability and prevents potential parsing issues.
Help: Wrap the variable in curly braces, e.g., `{$variable}`.
|
|
consistency/string-interpolation-braces:
src/Markdown/HandleParser.php#L36
Unbraced variable in string interpolation
Using curly braces around variables in interpolated strings improves readability and prevents potential parsing issues.
Help: Wrap the variable in curly braces, e.g., `{$variable}`.
|
|
consistency/string-interpolation-braces:
src/Markdown/HandleParser.php#L35
Unbraced variable in string interpolation
Using curly braces around variables in interpolated strings improves readability and prevents potential parsing issues.
Help: Wrap the variable in curly braces, e.g., `{$variable}`.
|