4 ms·

On the other hand, if you are writing repetitive code - are you missing an easy abstraction? Or if not, some easy code gen? If I find myself starting to write r

On the other hand, if you are writing repetitive code - are you missing an easy abstraction? Or if not, some easy code gen? If I find myself starting to write repetitive code It usually means I did something wrong.

skp1995 3y ago
This has more to do with the fact that copilot by nature is additive and not editing your code. There was a recent report about how code quality is dropping in codebases because of the repetitive code being introduced by copilot. The next evolution as you are saying would be to detect if its a repetitive code and modularise it or refactor it.
- thedougd 3y ago
  You can do this today with the VS Code extension. There’s a context menu for copilot to do things like “explain this code”. I asked it to make my current class more DRY and it refactored validation and parsing for a dozen or so arguments. It had one minor misunderstanding of my intent which I fixed by hand.
lolinder 3y ago
This is why I specifically identified that there there are cases where there is no reasonable abstraction. DRY has become so much of a mantra in the industry that it's taken for granted that any repetition must be unnecessary, but there are times where that's just wrong. The first example I gave is parsers—even after you've factored out as many helper functions as you can, you'll eventually hit a floor where you have to use those helper functions and piece the results together. That floor is necessarily repetitive—you end up with a bunch of 5 to 10 line functions calling the abstractions and feeding the results together. Unit tests is another example: I find that when people get too DRY in unit tests it just ends up obfuscating what the test is testing and makes changing the program later harder. Same as with parsing, there is a floor for how much abstraction is reasonable and once you have hit that floor you still have to go through the rote repetition of stringing functions together and asserting things about the results. With a parser you actually have to do this, but with unit tests people will as often as not give up on the tedium and just not cover all the edge cases. Copilot enables developers to stop writing the repetitive code and spend their unit testing time thinking of edge cases.
gs17 3y ago
Copilot is the easy code gen in this case. It's even surprisingly good at Rust macros.
- lolinder 3y ago
  Yes! It's surprisingly good at Rust in general, and does a better job with macros than intellisense does.
joshstrange 3y ago
This mentality has been taken entirely too far in software development. People think if they have to write the same single line more than once then they are doing it wrong. That could not be further from the truth. Unless you find yourself writing the exact block of code, without any modifications, 3 or more times it’s better to have the “duplicated” code. Until you hit 3+ times you are just guessing at future usage and in my experience developers, myself included, are terrible at guessing the future. I’ve watched “DRY” code turn into a monster when someone, like myself, tries to force a bunch of use cases into a single flow in order to be DRY. You end up with confusing code that’s trying to do too many things in a single function/block littered with if/else such that stepping through it (in your head) is complicated and error-prone. I regularly ask the developers who work under me to first duplicate the code and use it a few different times before going back and deciding “can this be made generic without standing on our heads?”. Recently I had to deal with an item list component that was made to display 2 vastly different types of data. The component was responsible for rendering out the items themselves since they had some UI similarities. The code is nightmare with a ton of input properties to tweak the display/functionality based on the type of item you want to render out. All in the name of DRY, the “well these look similar so we better abstract this and use it in both places”. When I was a younger developer I thought this way and wrote code this way. It’s unmaintainable, entirely too “clever” (that’s a bad thing), and hard to reason about. Nowadays I value readability and ease of understanding over “DRY for DRY’s sake”.
- jaredsohn 3y ago
  In case you're not aware of it the name for what you like is WET ("Write everything twice/thrice") rather than DRY.
- bioneuralnet 3y ago
  My experience exactly. I think the DRK (Don’t Repeat Knowledge) acronym (not my invention) is a better target. Too often people mistake similar structures of code as “repetition”. Instead, if you focus on not repeating the important “knowledge” of your code (algorithms, business rules, etc), it’s easier to avoid the trap of over-abstracting.

skp1995 3y ago

This has more to do with the fact that copilot by nature is additive and not editing your code. There was a recent report about how code quality is dropping in codebases because of the repetitive code being introduced by copilot. The next evolution as you are saying would be to detect if its a repetitive code and modularise it or refactor it.

thedougd 3y ago
You can do this today with the VS Code extension. There’s a context menu for copilot to do things like “explain this code”. I asked it to make my current class more DRY and it refactored validation and parsing for a dozen or so arguments. It had one minor misunderstanding of my intent which I fixed by hand.

lolinder 3y ago

This is why I specifically identified that there there are cases where there is no reasonable abstraction. DRY has become so much of a mantra in the industry that it's taken for granted that any repetition must be unnecessary, but there are times where that's just wrong. The first example I gave is parsers—even after you've factored out as many helper functions as you can, you'll eventually hit a floor where you have to use those helper functions and piece the results together. That floor is necessarily repetitive—you end up with a bunch of 5 to 10 line functions calling the abstractions and feeding the results together. Unit tests is another example: I find that when people get too DRY in unit tests it just ends up obfuscating what the test is testing and makes changing the program later harder. Same as with parsing, there is a floor for how much abstraction is reasonable and once you have hit that floor you still have to go through the rote repetition of stringing functions together and asserting things about the results. With a parser you actually have to do this, but with unit tests people will as often as not give up on the tedium and just not cover all the edge cases. Copilot enables developers to stop writing the repetitive code and spend their unit testing time thinking of edge cases.

gs17 3y ago

Copilot is the easy code gen in this case. It's even surprisingly good at Rust macros.

lolinder 3y ago
Yes! It's surprisingly good at Rust in general, and does a better job with macros than intellisense does.

joshstrange 3y ago

This mentality has been taken entirely too far in software development. People think if they have to write the same single line more than once then they are doing it wrong. That could not be further from the truth. Unless you find yourself writing the exact block of code, without any modifications, 3 or more times it’s better to have the “duplicated” code. Until you hit 3+ times you are just guessing at future usage and in my experience developers, myself included, are terrible at guessing the future. I’ve watched “DRY” code turn into a monster when someone, like myself, tries to force a bunch of use cases into a single flow in order to be DRY. You end up with confusing code that’s trying to do too many things in a single function/block littered with if/else such that stepping through it (in your head) is complicated and error-prone. I regularly ask the developers who work under me to first duplicate the code and use it a few different times before going back and deciding “can this be made generic without standing on our heads?”. Recently I had to deal with an item list component that was made to display 2 vastly different types of data. The component was responsible for rendering out the items themselves since they had some UI similarities. The code is nightmare with a ton of input properties to tweak the display/functionality based on the type of item you want to render out. All in the name of DRY, the “well these look similar so we better abstract this and use it in both places”. When I was a younger developer I thought this way and wrote code this way. It’s unmaintainable, entirely too “clever” (that’s a bad thing), and hard to reason about. Nowadays I value readability and ease of understanding over “DRY for DRY’s sake”.

jaredsohn 3y ago
In case you're not aware of it the name for what you like is WET ("Write everything twice/thrice") rather than DRY.
bioneuralnet 3y ago
My experience exactly. I think the DRK (Don’t Repeat Knowledge) acronym (not my invention) is a better target. Too often people mistake similar structures of code as “repetition”. Instead, if you focus on not repeating the important “knowledge” of your code (algorithms, business rules, etc), it’s easier to avoid the trap of over-abstracting.