Skip to content
New issue

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

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

Already on GitHub? # to your account

dan.chiniara/url-encoding-for-monitor-api #2249

Merged
merged 1 commit into from
Mar 18, 2025

Conversation

api-clients-generation-pipeline[bot]
Copy link
Contributor

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

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

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, :AuthZ]
auth_names = opts[:debug_auth_names] || %i[apiKeyAuth appKeyAuth AuthZ]
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

Comment on lines 1981 to 2004
"v2.GetRuleVersionHistory" => {
"rule_id" => "String",
"page_size" => "Integer",
"page_number" => "Integer",
},

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

# Get a rule's version history.
#
# @see #get_rule_version_history_with_http_info
def get_rule_version_history(rule_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

}

if attributes.key?(:'changes')
if (value = attributes[:'changes']).is_a?(Array)

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 Array() to ensure the type is that of an array (...read more)

The rule "Use Array() to ensure your variable is an array" is important for ensuring your code behaves as expected, regardless of the type of data it receives. It is common in Ruby to need to iterate through an array of items. However, if the variable is not an array, this can lead to unexpected behavior or errors.

The Array() method in Ruby is a Kernel method that converts its argument to an Array. If the argument is already an Array, it returns the argument. If the argument is nil, it returns an empty Array. This can be used to ensure that a variable is an array before trying to iterate over it, preventing potential errors or unexpected behavior.

By using Array(foos), you can ensure that foos is an array before you try to iterate over it with each. This prevents the need to check if foos is an array with foos.is_a?(Array) and makes your code cleaner and easier to understand.

View in Datadog  Leave us feedback  Documentation

# @option opts [Integer] :page_size Size for a given page. The maximum allowed value is 100.
# @option opts [Integer] :page_number Specific page number to return.
# @return [Array<(GetRuleVersionHistoryResponse, Integer, Hash)>] GetRuleVersionHistoryResponse data, response status code and response headers
def get_rule_version_history_with_http_info(rule_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

@datadog-datadog-prod-us1
Copy link

datadog-datadog-prod-us1 bot commented Feb 13, 2025

Datadog Report

Branch report: datadog-api-spec/generated/3575
Commit report: 085d840
Test service: datadog-api-client-ruby

✅ 0 Failed, 1121 Passed, 1978 Skipped, 1m 53.51s Total Time

@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3575 branch from 192117d to c13d171 Compare February 13, 2025 18:47
Copy link

This PR has been automatically marked as stale because it has not had activity in the last 30 days.
If there is no activity for another 90 days, this issue will be automatically closed.

@api-clients-generation-pipeline api-clients-generation-pipeline bot force-pushed the datadog-api-spec/generated/3575 branch from d34e4b4 to f591b49 Compare March 17, 2025 21:06
@github-actions github-actions bot removed the stale label Mar 18, 2025
@skarimo skarimo merged commit 5ab5990 into master Mar 18, 2025
16 checks passed
@skarimo skarimo deleted the datadog-api-spec/generated/3575 branch March 18, 2025 12:19
github-actions bot pushed a commit that referenced this pull request Mar 18, 2025
Co-authored-by: ci.datadog-api-spec <packages@datadoghq.com> 5ab5990
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants