-
Notifications
You must be signed in to change notification settings - Fork 22
Edit Naming for v2 Microsoft Teams Integration Endpoints #2044
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.
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
Edit Naming for v2 Microsoft Teams Integration Endpoints #2044
Conversation
| # @return [Array<(MicrosoftTeamsApiHandleInfoResponse, Integer, Hash)>] MicrosoftTeamsApiHandleInfoResponse data, response status code and response headers | ||
| def get_api_handle_with_http_info(handle_id, opts = {}) | ||
| # @return [Array<(MicrosoftTeamsGetChannelByNameResponse, Integer, Hash)>] MicrosoftTeamsGetChannelByNameResponse data, response status code and response headers | ||
| def get_channel_by_name_with_http_info(tenant_name, team_name, channel_name, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| def create_api_handle(body, opts = {}) | ||
| data, _status_code, _headers = create_api_handle_with_http_info(body, opts) | ||
| # @see #create_tenant_based_handle_with_http_info | ||
| def create_tenant_based_handle(body, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| def update_api_handle(handle_id, body, opts = {}) | ||
| data, _status_code, _headers = update_api_handle_with_http_info(handle_id, body, opts) | ||
| # @see #update_tenant_based_handle_with_http_info | ||
| def update_tenant_based_handle(handle_id, body, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| require "datadog_api_client" | ||
| api_instance = DatadogAPIClient::V2::MicrosoftTeamsIntegrationAPI.new | ||
| p api_instance.list_api_handles() | ||
| p api_instance.list_tenant_based_handles() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
| p api_instance.list_tenant_based_handles() | |
| p api_instance.list_tenant_based_handles |
Do not use parentheses with methods that take no arguments (...read more)
The rule "Avoid parentheses when methods take no arguments" is part of the Ruby style guide. It suggests that when a method takes no arguments, you should not use parentheses. This is because the use of parentheses in such a case is redundant and unnecessary, and it can make your code more difficult to read and understand.
This rule is important because it promotes cleaner, more readable code. In Ruby, clean and readable code is highly valued. By following this rule, you can ensure your code is easier to understand and maintain, which is crucial for long-term project success.
To adhere to this rule, remove the parentheses when calling a method that does not require any arguments. For example, instead of writing 'test'.upcase(), you should write 'test'.upcase. Similarly, instead of Kernel.exit!(), write Kernel.exit!. However, note that there is an exception for super - super by itself is different from super(), so in this case, parentheses may be necessary.
| def list_api_handles_with_http_info(opts = {}) | ||
| # @option opts [String] :name Your tenant-based handle name. | ||
| # @return [Array<(MicrosoftTeamsTenantBasedHandlesResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandlesResponse data, response status code and response headers | ||
| def list_tenant_based_handles_with_http_info(opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| def get_api_handle(handle_id, opts = {}) | ||
| data, _status_code, _headers = get_api_handle_with_http_info(handle_id, opts) | ||
| # @see #get_channel_by_name_with_http_info | ||
| def get_channel_by_name(tenant_name, team_name, channel_name, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| # @param opts [Hash] the optional parameters | ||
| # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers | ||
| def delete_api_handle_with_http_info(handle_id, opts = {}) | ||
| def delete_tenant_based_handle_with_http_info(handle_id, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| # @return [Array<(MicrosoftTeamsCreateApiHandleResponse, Integer, Hash)>] MicrosoftTeamsCreateApiHandleResponse data, response status code and response headers | ||
| def create_api_handle_with_http_info(body, opts = {}) | ||
| # @return [Array<(MicrosoftTeamsTenantBasedHandleResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandleResponse data, response status code and response headers | ||
| def create_tenant_based_handle_with_http_info(body, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| # @return [Array<(MicrosoftTeamsApiHandleInfoResponse, Integer, Hash)>] MicrosoftTeamsApiHandleInfoResponse data, response status code and response headers | ||
| def update_api_handle_with_http_info(handle_id, body, opts = {}) | ||
| # @return [Array<(MicrosoftTeamsTenantBasedHandleResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandleResponse data, response status code and response headers | ||
| def update_tenant_based_handle_with_http_info(handle_id, body, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
| # @return [Array<(MicrosoftTeamsGetChannelByNameResponse, Integer, Hash)>] MicrosoftTeamsGetChannelByNameResponse data, response status code and response headers | ||
| def get_channel_by_name_with_http_info(tenant_name, team_name, channel_name, opts = {}) | ||
| # @return [Array<(MicrosoftTeamsTenantBasedHandleResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandleResponse data, response status code and response headers | ||
| def get_tenant_based_handle_with_http_info(handle_id, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.
e8e21f7 to
ee1a09d
Compare
Co-authored-by: ci.datadog-api-spec <[email protected]> 2def574
See DataDog/datadog-api-spec#3165
Test branch datadog-api-spec/test/kalil.black/CHATINTS-383/ms-teams-api-spec-refactor