Skip to content
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

add docs for pagination in /api/v2/metrics endpoint #2021

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

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

api_version = "V2"
page_size = @api_client.get_attribute_from_path(opts, "page_size", 10000)
@api_client.set_attribute_from_path(api_version, opts, "page_size", Integer, page_size)
while true do

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
while true do
loop do do
Don't use the expression `while true` for an infinite loop (...read more)

The Ruby static analysis rule "Use Kernel#loop instead of while/until" focuses on promoting the use of Kernel#loop for infinite loops rather than while true or until false. This is because Kernel#loop is more idiomatic to Ruby, and it communicates the intent of an infinite loop more clearly. This rule helps to maintain readability, which is crucial in large codebases where understanding the flow and function of the code is important.

The while true or until false expressions can be misleading as they suggest a condition that might change, even though they are used to create infinite loops. Using Kernel#loop eliminates this ambiguity, making the code easier to understand.

To adhere to this rule, replace any while true or until false loops with Kernel#loop. The body of the loop remains the same. This small change can significantly improve the clarity of the code, making it more understandable for other developers who might work on the same codebase.

View in Datadog  Leave us feedback  Documentation


require "datadog_api_client"
api_instance = DatadogAPIClient::V2::MetricsAPI.new
api_instance.list_tag_configurations_with_pagination() { |item| puts item }

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
api_instance.list_tag_configurations_with_pagination() { |item| puts item }
api_instance.list_tag_configurations_with_pagination { |item| puts item }
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

# To use it you need to use a block: list_tag_configurations_with_pagination { |item| p item }
#
# @yield [MetricsAndMetricTagConfigurations] Paginated items
def list_tag_configurations_with_pagination(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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants