Skip to content

Order of arguments good practise #3760

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 2, 2024
Merged

Order of arguments good practise #3760

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
afdfdda
Order of arguments good practise
AbrilRBS Jun 5, 2024
b1e409d
Add also note about using = when adding values to named args
AbrilRBS Jun 5, 2024
46f1f0f
Rewording
AbrilRBS Jun 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions knowledge/guidelines.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,9 @@ Good practices
the graph to avoid the conflicts without overrides and forces is the recommended approach.
- **Please, do not abuse 'tool_requires'**. Those are intended only for executables like ``cmake`` and ``ninja`` running in the "build"
context, not for libraries or library-like dependencies, that must use ``requires`` or ``test_requires``.
- Named arguments which receive a value should use ``=`` without spaces. For example, ``-r=conancenter`` is correct, but ``-r conancenter`` is not.
- Positional arguments when invoking Conan should be specified first, before any named argument. For example,
``conan install . -s="os=Windows"`` is correct, but ``conan install -s="os=Windows" .`` is not.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not fully sure. The -r conancenter does work, so maybe we want to reword a bit? I'd do:

  • Use just 1 item to define both good practices for CLI args, not 2 bullet items
  • Define the good practice without saying that the other is not correct (positive recommendation), just recommend one over the other (it can be said that there can be arg parsing errors if not in some cases)


Forbidden practices
-------------------
Expand Down