Type Error, Random buffer, and Core #4327
Conversation
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| # Steep doesn't like an array with up to 3 elements to be passed here: it thinks the array is unbounded. | ||
| when Array then new(*value) | ||
| # Steep can follow the logic inside the lambda, thus it doesn't know `value` responds to `:message`. | ||
| when ->(v) { v.respond_to?(:message) } then new(value.class, value.message) |
There was a problem hiding this comment.
⚪ Code Quality Violation
| when ->(v) { v.respond_to?(:message) } then new(value.class, value.message) | |
| when ->(v) { v.respond_to?(:message) }new(value.class, value.message) |
Don't use `then` for multi-line if, unless, when, or in statements (...read more)
The then keyword is not necessary in multi-line if/unless/when/in statements in Ruby. When used in multi-line statements, it can make the code harder to read and understand. This is because then is typically associated with single-line conditional statements in Ruby, and its use in multi-line statements can be confusing.
Maintaining readability and clarity in your code is crucial for effective collaboration and debugging. It becomes even more important in larger codebases, where complex logic can become difficult to follow if not written clearly.
To avoid this issue, omit the then keyword in your multi-line if/unless/when/in statements. For single-line if/unless/when/in statements, using then is acceptable and can help improve readability. This practice keeps your code clean and easy to understand, following the principles of good coding practices.
| when ContainsMessage then new(value.class, value.message) | ||
| # steep:ignore:start | ||
| # Steep doesn't like an array with up to 3 elements to be passed here: it thinks the array is unbounded. | ||
| when Array then new(*value) |
There was a problem hiding this comment.
⚪ Code Quality Violation
| when Array then new(*value) | |
| when Arraynew(*value) |
Don't use `then` for multi-line if, unless, when, or in statements (...read more)
The then keyword is not necessary in multi-line if/unless/when/in statements in Ruby. When used in multi-line statements, it can make the code harder to read and understand. This is because then is typically associated with single-line conditional statements in Ruby, and its use in multi-line statements can be confusing.
Maintaining readability and clarity in your code is crucial for effective collaboration and debugging. It becomes even more important in larger codebases, where complex logic can become difficult to follow if not written clearly.
To avoid this issue, omit the then keyword in your multi-line if/unless/when/in statements. For single-line if/unless/when/in statements, using then is acceptable and can help improve readability. This practice keeps your code clean and easy to understand, following the principles of good coding practices.
Datadog ReportBranch report: ✅ 0 Failed, 22098 Passed, 1476 Skipped, 5m 8.44s Total Time |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4327 +/- ##
==========================================
+ Coverage 97.72% 97.73% +0.01%
==========================================
Files 1368 1368
Lines 82997 82995 -2
Branches 4219 4219
==========================================
+ Hits 81105 81113 +8
+ Misses 1892 1882 -10 ☔ View full report in Codecov by Sentry. |
| # steep:ignore:start | ||
| # Steep doesn't like an array with up to 3 elements to be passed here: it thinks the array is unbounded. | ||
| when Array then new(*value) | ||
| # Steep can follow the logic inside the lambda, thus it doesn't know `value` responds to `:message`. |
There was a problem hiding this comment.
| # Steep can follow the logic inside the lambda, thus it doesn't know `value` responds to `:message`. | |
| # Steep can not follow the logic inside the lambda, thus it doesn't know `value` responds to `:message`. |
| when Array then new(*value) | ||
| # Steep can follow the logic inside the lambda, thus it doesn't know `value` responds to `:message`. | ||
| when ->(v) { v.respond_to?(:message) } then new(value.class, value.message) | ||
| # steep:ignore:end | ||
| when String then new(nil, value) |
There was a problem hiding this comment.
We have Error.new lower, does it makes sense to have the same here or there?
| @items: Array[Object] | ||
| @max_size: Integer | ||
|
|
||
| def initialize: (Integer)-> void |
There was a problem hiding this comment.
| def initialize: (Integer)-> void | |
| def initialize: (Integer) -> void |
|
|
||
| def add!: (Object) -> Object | ||
|
|
||
| def add_all!: (Array[Object])-> void |
There was a problem hiding this comment.
| def add_all!: (Array[Object])-> void | |
| def add_all!: (Array[Object]) -> void |
|
|
||
| def push: (Object) -> Object? | ||
|
|
||
| def replace!: (Object)-> Object? |
There was a problem hiding this comment.
| def replace!: (Object)-> Object? | |
| def replace!: (Object) -> Object? |
| @@ -2,6 +2,37 @@ module Datadog | |||
| module Core | |||
| module Buffer | |||
| class Random | |||
| @closed: bool | |||
| @items: Array[Object] | |||
There was a problem hiding this comment.
Does it makes sense to extract it as a type alias here and use in all the latter sigs in this file?
|
LGTM, I also agree with the suggested changes |
Remove the steep
ignoredirective for 3 more files:datadog/core/error.rb,datadog/core/buffer/random.rb, anddatadog/core.rb.Change log entry
No