-
Notifications
You must be signed in to change notification settings - Fork 19
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
Create AWS Integrations v2 API spec #1846
base: master
Are you sure you want to change the base?
Create AWS Integrations v2 API spec #1846
Conversation
75cc225
to
00baa60
Compare
This issue has been automatically marked as stale because it has not had activity in the last 30 days. |
e0ddb64
to
5856149
Compare
c445ae0
to
93cfbea
Compare
15407fb
to
c8c856b
Compare
d155dfe
to
51bf0e7
Compare
d9b90aa
to
7998eb4
Compare
# @param body [AWSAccountCreateRequest] | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSAccountResponse, Integer, Hash)>] AWSAccountResponse data, response status code and response headers | ||
def create_aws_account_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.
} | ||
|
||
if attributes.key?(:'include_only') | ||
if (value = attributes[:'include_only']).is_a?(Array) |
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
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.
features/scenarios_model_mapping.rb
Outdated
"v2.DeleteAWSAccount" => { | ||
"aws_account_id" => "String", | ||
}, |
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
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.
} | ||
|
||
if attributes.key?(:'lambdas') | ||
if (value = attributes[:'lambdas']).is_a?(Array) |
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
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.
sources: [ | ||
"s3", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
end | ||
|
||
if attributes.key?(:'sources') | ||
if (value = attributes[:'sources']).is_a?(Array) |
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
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.
# AWS Integration - Get all account configs. | ||
# | ||
# @see #list_aws_accounts_with_http_info | ||
def list_aws_accounts(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 aws_account_id [String] The ID of the AWS Account Integration Config | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSAccountResponse, Integer, Hash)>] AWSAccountResponse data, response status code and response headers | ||
def get_aws_account_with_http_info(aws_account_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.
# AWS Integration - Create account config. | ||
# | ||
# @see #create_aws_account_with_http_info | ||
def create_aws_account(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.
} | ||
|
||
if attributes.key?(:'exclude_only') | ||
if (value = attributes[:'exclude_only']).is_a?(Array) |
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
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.
This PR has been automatically marked as stale because it has not had activity in the last 30 days. |
1edc754
to
edaf77a
Compare
# header parameters | ||
header_params = opts[:header_params] || {} | ||
# HTTP header 'Accept' (if needed) | ||
header_params['Accept'] = @api_client.select_header_accept(['application/json']) |
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
header_params['Accept'] = @api_client.select_header_accept(['application/json']) | |
header_params['Accept'] = @api_client.select_header_accept(%w[application/json]) |
Consider using the %w syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
return_type = opts[:debug_return_type] || 'AWSAccountResponse' | ||
|
||
# auth_names | ||
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] |
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
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.
include_only: [ | ||
"AWS/EC2", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
include_only: [ | ||
"AWS/EC2", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
# HTTP header 'Accept' (if needed) | ||
header_params['Accept'] = @api_client.select_header_accept(['application/json']) | ||
# HTTP header 'Content-Type' | ||
header_params['Content-Type'] = @api_client.select_header_content_type(['application/json']) |
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
header_params['Content-Type'] = @api_client.select_header_content_type(['application/json']) | |
header_params['Content-Type'] = @api_client.select_header_content_type(%w[application/json]) |
Consider using the %w syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
# header parameters | ||
header_params = opts[:header_params] || {} | ||
# HTTP header 'Accept' (if needed) | ||
header_params['Accept'] = @api_client.select_header_accept(['application/json']) |
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
header_params['Accept'] = @api_client.select_header_accept(['application/json']) | |
header_params['Accept'] = @api_client.select_header_accept(%w[application/json]) |
Consider using the %w syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
include_only: [ | ||
"us-east-1", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
return_type = opts[:debug_return_type] || 'AWSAccountsResponse' | ||
|
||
# auth_names | ||
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] |
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
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.
edaf77a
to
9dc40a6
Compare
# header parameters | ||
header_params = opts[:header_params] || {} | ||
# HTTP header 'Accept' (if needed) | ||
header_params['Accept'] = @api_client.select_header_accept(['application/json']) |
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
header_params['Accept'] = @api_client.select_header_accept(['application/json']) | |
header_params['Accept'] = @api_client.select_header_accept(%w[application/json]) |
Consider using the %w syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
return_type = opts[:debug_return_type] || 'AWSAccountResponse' | ||
|
||
# auth_names | ||
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] |
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
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.
"v2.ListAWSAccounts" => { | ||
"aws_account_id" => "String", | ||
}, |
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
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.
"v2.GetAWSAccount" => { | ||
"aws_account_config_id" => "String", | ||
}, |
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
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.
"v2.DeleteAWSAccount" => { | ||
"aws_account_config_id" => "String", | ||
}, |
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
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.
# AWS Integration - Patch account config. | ||
# | ||
# @see #update_aws_account_with_http_info | ||
def update_aws_account(aws_account_config_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.
# @param body [AWSAccountPatchRequest] | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSAccountResponse, Integer, Hash)>] AWSAccountResponse data, response status code and response headers | ||
def update_aws_account_with_http_info(aws_account_config_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.
"v2.UpdateAWSAccount" => { | ||
"aws_account_config_id" => "String", | ||
"body" => "AWSAccountPatchRequest", | ||
}, |
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
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.
9dc40a6
to
a56ba4f
Compare
# AWS Integration - Delete account config. | ||
# | ||
# @see #delete_aws_account_with_http_info | ||
def delete_aws_account(aws_account_config_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.
# @param aws_account_config_id [String] Unique Datadog ID of the AWS Account Integration Config | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers | ||
def delete_aws_account_with_http_info(aws_account_config_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.
# AWS Integration - Get account config. | ||
# | ||
# @see #get_aws_account_with_http_info | ||
def get_aws_account(aws_account_config_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.
a56ba4f
to
fbcc637
Compare
return_type = opts[:debug_return_type] | ||
|
||
# auth_names | ||
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] |
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
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.
tags: [ | ||
"key:value", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
account_tags: [ | ||
"key:value", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
account_tags: [ | ||
"key:value", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
2326dc2
to
ec07863
Compare
tags: [ | ||
"key:value", | ||
], |
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
Consider using the %W syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
e3a2a5c
to
1f8e98b
Compare
return_type = opts[:debug_return_type] || 'AWSLogsServicesResponse' | ||
|
||
# auth_names | ||
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth] |
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
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.
config.unstable_operations["v2.generate_new_external_id".to_sym] = true | ||
end | ||
api_instance = DatadogAPIClient::V2::AWSIntegrationAPI.new | ||
p api_instance.generate_new_external_id() |
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.generate_new_external_id() | |
p api_instance.generate_new_external_id |
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.
} | ||
|
||
if attributes.key?(:'data') | ||
if (value = attributes[:'data']).is_a?(Array) |
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
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.
# | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSLogsServicesResponse, Integer, Hash)>] AWSLogsServicesResponse data, response status code and response headers | ||
def list_aws_log_services_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.
# | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSNamespacesResponse, Integer, Hash)>] AWSNamespacesResponse data, response status code and response headers | ||
def list_aws_namespaces_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.
|
||
require "datadog_api_client" | ||
api_instance = DatadogAPIClient::V2::AWSIntegrationAPI.new | ||
p api_instance.list_aws_log_services() |
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_aws_log_services() | |
p api_instance.list_aws_log_services |
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.
# @param aws_account_config_id [String] Unique Datadog ID of the AWS Account Integration Config | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSAccountResponse, Integer, Hash)>] AWSAccountResponse data, response status code and response headers | ||
def get_aws_account_with_http_info(aws_account_config_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.
} | ||
|
||
if attributes.key?(:'logs_services') | ||
if (value = attributes[:'logs_services']).is_a?(Array) |
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
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.
# | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(AWSNewExternalIDResponse, Integer, Hash)>] AWSNewExternalIDResponse data, response status code and response headers | ||
def generate_new_external_id_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.
# AWS Integration - List namespaces. | ||
# | ||
# @see #list_aws_namespaces_with_http_info | ||
def list_aws_namespaces(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.
819dc38
to
e2d0cbc
Compare
} | ||
|
||
if attributes.key?(:'namespaces') | ||
if (value = attributes[:'namespaces']).is_a?(Array) |
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
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.
config.unstable_operations["v2.list_aws_namespaces".to_sym] = true | ||
end | ||
api_instance = DatadogAPIClient::V2::AWSIntegrationAPI.new | ||
p api_instance.list_aws_namespaces() |
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_aws_namespaces() | |
p api_instance.list_aws_namespaces |
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.
# header parameters | ||
header_params = opts[:header_params] || {} | ||
# HTTP header 'Accept' (if needed) | ||
header_params['Accept'] = @api_client.select_header_accept(['application/json']) |
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
header_params['Accept'] = @api_client.select_header_accept(['application/json']) | |
header_params['Accept'] = @api_client.select_header_accept(%w[application/json]) |
Consider using the %w syntax instead (...read more)
The rule "Prefer %w
to the literal array syntax" is a Ruby style guideline that encourages the use of %w
notation instead of the traditional array syntax when defining arrays of strings. This rule is part of the Ruby community's efforts to promote readability and simplicity in Ruby code.
This rule is important because it helps to keep the code concise and easy to read. The %w
notation allows you to define an array of strings without having to use quotes and commas. This can make the code cleaner and easier to understand, especially when dealing with large arrays.
To follow this rule, replace the traditional array syntax with the %w
notation. For example, instead of writing ['foo', 'bar', 'baz']
, you should write %w[foo bar baz]
. This will create the same array, but in a more readable and concise way. By following this rule, you can help to make your Ruby code cleaner and easier to understand.
e2d0cbc
to
047b9b0
Compare
See DataDog/datadog-api-spec#2813
Test branch datadog-api-spec/test/jon.vanbriesen/aws-v2-spec