zlacker

I can't recall a single time that's been common advice given to programmers. It's usually either don't reinvent the wheel (therefore use the source while adhering to license), or come up with your own solution.

Don't know how you would even write code in your own style. As soon as you start altering it, the result is different. It's more/less efficient.

>>wabore+(OP)
I interpreted the comment you are responding to as “make sure it uses the same style conventions as the rest of this file”, which is something that Copilot does very well!

>>wabore+(OP)
Depending on language there are ton of style choices. There’s style guides as examples of trivial.

Non trivial include names, comments, logging, error checking, structure, ordering of operations that aren’t sequential.

>>wabore+(OP)
this comment really hits hard for me -- its like there is a place to buy food where every menu item is clearly shown, with a large color picture and a printed price.. and the person talking has only every purchased food in that way.. as if there are no alternatives that "really exist"

there really are a lot of other scenarios that involve writing software, to make software. Its not possible to list them all.. the list changes while I type

>>njharm+53
Yes, but all of those have impact to the actual function and performance of the proposed solution. By doing so, you are changing the solution.

Look at FizzBuzz. If you were to set strict requirements on performance (and allow for reiterative testing), the results from different groups of people would be identical. They would reach the same conclusion because that's how code works, it's far more aligned to math than it is creative writing.

So you cannot take an existing code solution and translate it to your own style. You are altering the program, the efficiency, and therefore the solution itself. Even when you do something like changing 1 single variable name!

>>wabore+(OP)
How do you like to name varibles. Do you use constant == variable or variable == constant. Tabs vs spaces. Declarations inline with first use, or at the top as K&R intended. Comment syntax and content. Etc.

Lots of little things.