-
Notifications
You must be signed in to change notification settings - Fork 20
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 deleteCustomFramework endpoint #2185
base: master
Are you sure you want to change the base?
add deleteCustomFramework endpoint #2185
Conversation
# @param org_id [String] The ID of the organization. | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(SecurityMonitoringListCustomFrameworksResponse, Integer, Hash)>] SecurityMonitoringListCustomFrameworksResponse data, response status code and response headers | ||
def list_custom_frameworks_with_http_info(org_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.
"v2.DeleteRole" => { | ||
"role_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.ListRoleUsers" => { | ||
"role_id" => "String", | ||
"page_size" => "Integer", | ||
"page_number" => "Integer", | ||
"sort" => "String", | ||
"filter" => "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.
# List custom frameworks. | ||
# | ||
# @see #list_custom_frameworks_with_http_info | ||
def list_custom_frameworks(org_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.
"v2.CloneRole" => { | ||
"role_id" => "String", | ||
"body" => "RoleCloneRequest", | ||
}, |
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.RemoveUserFromRole" => { | ||
"role_id" => "String", | ||
"body" => "RelationshipToUser", | ||
}, |
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.ListRolePermissions" => { | ||
"role_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.CreateRole" => { | ||
"body" => "RoleCreateRequest", | ||
}, |
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.AddPermissionToRole" => { | ||
"role_id" => "String", | ||
"body" => "RelationshipToPermission", | ||
}, |
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.RemovePermissionFromRole" => { | ||
"role_id" => "String", | ||
"body" => "RelationshipToPermission", | ||
}, |
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.
1f8fa5b
to
3c6d3a7
Compare
# Delete a custom framework. | ||
# | ||
# @see #delete_custom_framework_with_http_info | ||
def delete_custom_framework(org_id, handle, version, 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 version [String] The framework version. | ||
# @param opts [Hash] the optional parameters | ||
# @return [Array<(DeleteCustomFrameworkResponse, Integer, Hash)>] DeleteCustomFrameworkResponse data, response status code and response headers | ||
def delete_custom_framework_with_http_info(org_id, handle, version, 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.
3c6d3a7
to
098f859
Compare
See DataDog/datadog-api-spec#3475
Test branch datadog-api-spec/test/vbarth/add-api-for-custom-terraform-plugin