Re:The Good and the Limitations of Github Copilot
by shadowgovt on Monday July 05, 2021 @09:30AM
(#27737771)
It's context-specific whether recalculation is a code smell. I've definitely gotten feedback from senior developers to just do len(x) repeatedly instead of "littering" (their words) the code with `xCount=len(x)` assignments (because they knew len was constant-time).
[ Parent
| on HN ]
Re:The Good and the Limitations of Github Copilot
by cf499 on Monday July 05, 2021 @09:56AM
(#27738026)
Sure, it makes sense if you find something like `len_x` or `x_count` significantly less readable than `len(x)` and if you don't have to worry about resources. Can't say I've been there though.
I did a quick test of this `reverse` function (which probably shouldn't exist in the first place) and, unsurprisingly, it became ~30% faster when `len(arr)` was only called once.
Re:The Good and the Limitations of Github Copilot
by shadowgovt on Monday July 05, 2021 @10:11AM
(#27738186)
When I'm that resource constrained, I don't use Python. The changes necessary to make regular Python code performant defeat the goal of making it readable.
There's a reason NumPy's innards aren't Python code.
Re:The Good and the Limitations of Github Copilot
by cf499 on Monday July 05, 2021 @10:53AM
(#27738572)
Both sides of this "readability vs. performance" debate can be argued ad absurdum but that's not my intention. All I know is that I try to conserve resources no matter what level of the stack I'm working on and those generated snippets certainly don't!
Re:The Good and the Limitations of Github Copilot
by shadowgovt on Monday July 05, 2021 @01:51PM
(#27740257)
Indeed, but they're not intended to. Nothing about Copilot's specs even claims it's generating optimally-performant code. And the Python example indicates why that may not even be a desirable output (most performant and most readable are orthogonal metrics).