Skip to content

Conversation

@api-clients-generation-pipeline
Copy link
Contributor

@api-clients-generation-pipeline api-clients-generation-pipeline bot requested a review from a team as a code owner September 27, 2024 20:19
@api-clients-generation-pipeline api-clients-generation-pipeline bot changed the title [TEST] Ignore pr [TEST] Add support for multi form parameter support Sep 30, 2024
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from 9075671 to 4f13f48 Compare September 30, 2024 19:17
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from 4f13f48 to 0bd1864 Compare October 3, 2024 20:04
def delete_tenant_based_handle(handle_id, opts = {})
delete_tenant_based_handle_with_http_info(handle_id, opts)
# @see #delete_api_handle_with_http_info
def delete_api_handle(handle_id, opts = {})

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.

View in Datadog  Leave us feedback  Documentation

Comment on lines 1328 to 1330
"v2.CreateApiHandle" => {
"body" => "MicrosoftTeamsCreateApiHandleRequest",
},

Choose a reason for hiding this comment

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

Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

return_type = opts[:debug_return_type] || 'MicrosoftTeamsApiHandleInfoResponse'

# auth_names
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth]

Choose a reason for hiding this comment

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

Code Quality Violation

Suggested change
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth]
auth_names = opts[:debug_auth_names] || %i[apiKeyAuth appKeyAuth]
Consider using the %i syntax instead (...read more)

The rule "Prefer %i to the literal array syntax" is a guideline that encourages the use of the %i syntax for arrays of symbols. This is a part of the Ruby style guide that aims to promote conciseness and readability.

Symbols are immutable, reusable objects often used in Ruby instead of strings when the value does not need to be changed. When declaring an array of symbols, using the %i syntax can make your code cleaner and easier to read.

To adhere to this rule, instead of declaring an array of symbols using the literal array syntax like [:foo, :bar, :baz], use the %i syntax like %i[foo bar baz]. It's a good practice to consistently use %i for arrays of symbols as it enhances code readability and maintainability.

View in Datadog  Leave us feedback  Documentation


require "datadog_api_client"
api_instance = DatadogAPIClient::V2::MicrosoftTeamsIntegrationAPI.new
p api_instance.list_api_handles()

Choose a reason for hiding this comment

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

Code Quality Violation

Suggested change
p api_instance.list_api_handles()
p api_instance.list_api_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.

View in Datadog  Leave us feedback  Documentation

# @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 = {})
# @return [Array<(MicrosoftTeamsApiHandleInfoResponse, Integer, Hash)>] MicrosoftTeamsApiHandleInfoResponse data, response status code and response headers
def update_api_handle_with_http_info(handle_id, body, opts = {})

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.

View in Datadog  Leave us feedback  Documentation

# @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<(MicrosoftTeamsApiHandleInfoResponse, Integer, Hash)>] MicrosoftTeamsApiHandleInfoResponse data, response status code and response headers
def get_api_handle_with_http_info(handle_id, opts = {})

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.

View in Datadog  Leave us feedback  Documentation

# @return [Array<(MicrosoftTeamsTenantBasedHandleResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandleResponse data, response status code and response headers
def get_tenant_based_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 = {})

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.

View in Datadog  Leave us feedback  Documentation

def create_tenant_based_handle(body, opts = {})
data, _status_code, _headers = create_tenant_based_handle_with_http_info(body, opts)
# @see #create_api_handle_with_http_info
def create_api_handle(body, opts = {})

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.

View in Datadog  Leave us feedback  Documentation

# @return [Array<(MicrosoftTeamsTenantBasedHandlesResponse, Integer, Hash)>] MicrosoftTeamsTenantBasedHandlesResponse data, response status code and response headers
def list_tenant_based_handles_with_http_info(opts = {})
# @return [Array<(MicrosoftTeamsApiHandlesResponse, Integer, Hash)>] MicrosoftTeamsApiHandlesResponse data, response status code and response headers
def list_api_handles_with_http_info(opts = {})

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.

View in Datadog  Leave us feedback  Documentation

def list_tenant_based_handles(opts = {})
data, _status_code, _headers = list_tenant_based_handles_with_http_info(opts)
# @see #list_api_handles_with_http_info
def list_api_handles(opts = {})

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.

View in Datadog  Leave us feedback  Documentation

@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from 0bd1864 to 8a9f236 Compare October 21, 2024 20:10
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from 8a9f236 to f41e740 Compare October 21, 2024 20:32
@api-clients-generation-pipeline api-clients-generation-pipeline bot changed the title [TEST] Add support for multi form parameter support Add support for multi form parameter support Oct 22, 2024
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch 2 times, most recently from 6e97f28 to e680014 Compare October 22, 2024 18:13
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from e680014 to fdf00c2 Compare October 28, 2024 19:24
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch 2 times, most recently from 4148497 to 969a19d Compare November 4, 2024 17:51
@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3157 branch from 969a19d to d028084 Compare November 4, 2024 18:35
@api-clients-generation-pipeline api-clients-generation-pipeline bot merged commit 4e5eefd into master Nov 4, 2024
15 checks passed
@api-clients-generation-pipeline api-clients-generation-pipeline bot deleted the datadog-api-spec/generated/3157 branch November 4, 2024 19:17
github-actions bot pushed a commit that referenced this pull request Nov 4, 2024
* mult form parameter support

* only add non rails for some apis

* Regenerate client from commit aeb956c4 of spec repo

---------

Co-authored-by: Anika Maskara <[email protected]>
Co-authored-by: api-clients-generation-pipeline[bot] <54105614+api-clients-generation-pipeline[bot]@users.noreply.github.com>
Co-authored-by: ci.datadog-api-spec <[email protected]> 4e5eefd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants