blocks|key|1966090|text|我听过有人说will复制和粘贴一次(最多将代码复制限制在两个实例中)，因为除非您在三个或更多的地方使用代码，否则抽象不会产生效果。我自己，一旦我觉得有必要，我就设法使它成为一种良好的重构习惯。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1966091|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I've heard people say the will copy and paste once (limiting duplication of code to at most two instances), as abstractions don't pay off unless you use the code in three places or more. () Myself, I try to make it a good habit of refactoring as soon as I see the need.

blocks|key|431841|text|问这个关于你的功能的问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431842|“如果这个小需求发生变化，我是否必须改变这两个功能才能满足它？”|431843|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Ask this question about your functions

"if this small requirement changes, will I have to change both functions in order to satisfy it?"

blocks|key|749165|text|当然有时候是可以接受的。这就是人们保存片段文件的原因。但是，如果您经常剪切和粘贴代码，或者使用几行以上的代码，那么您应该考虑将其作为一个子程序。为什么？因为你必须改变一些事情，这样的话，你只需要改变一次。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749166|中间的大小写是使用宏，如果您有这样的可用。|749167|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Of course it's sometimes acceptable. That's why people keep snippet files. But if you're cutting and pasting code very often, or with more than a few lines, you should think about making it a subroutine. Why? because odds on you'll have to change something, and this way, you only need to change it once.

Middle case is to use a macro if you have such available.

blocks|key|1965650|text|是的，就像你说的那样；细微的，但难以接受的变化。如果情况真的需要这样做，就不要责备自己。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1965651|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, and it's exactly as you say; minor but hard-to-factor variations. Don't flagellate yourself if it's really what the situation calls for.

blocks|key|749875|text|Re以前是可以接受的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749876|是。当该部分稍有不同，并且您正在执行一次性系统(系统在那里的时间非常短，不需要维护)。否则，通常更好地提取共性。|749877|Re片段看起来类似但不完全相同：|749878|如果差异在数据中，则通过提取函数并使用数据中的差异作为参数进行重构(如果有太多的数据不能作为参数传递，请考虑将它们分组到一个对象或结构中)。如果在函数的某些过程中存在差异，则使用命令模式或抽象模板进行重构。如果即使使用这些设计模式也很难重构，那么您的函数可能会尝试自己处理许多责任。|749879|例如，如果有一个代码段在两个段中不同--+diff#1和diff#2；在diff#1中，可以使用diff1A或diff1B，而对于diff#2，则可以使用diff2A和diff2B。|749880|如果diff1A和diff2A总是在一起，diff1B和diff2B总是在一起，那么diff1A和diff2A可以包含在一个命令类或一个抽象模板实现中，而diff1B和diff2B可以包含在另一个命令类或抽象模板实现中。|749881|但是，如果有几个组合(即diff1A+&+diff2A、diff1A+&+diff2B、diff1B+&+diff2A、diff1B+&+diff2B+)，那么您可能需要重新考虑您的功能，因为它可能试图单独处理太多的责任。|749882|关于SQL语句：|749883|使用逻辑(如果-否则，循环)来动态构建SQL牺牲可读性。但是，创建所有SQL变体将很难维护。因此，在中途相遇，并使用SQL段。将共性提取为SQL段，并以这些SQL段作为常量创建所有SQL变体。|749884|例如：|749885|private+static+final+String+EMPLOYEE_COLUMNS+=+"+id,+fName,+lName,+status";

private+static+final+String+EMPLOYEE_TABLE+=+"+employee";

private+static+final+String+EMPLOYEE_HAS_ACTIVE_STATUS+=+"+employee";

private+static+final+String+GET_EMPLOYEE_BY_STATUS+=
++"+select"+%2B+EMPLOYEE_COLUMNS+%2B+"+from"+%2B+EMPLOYEE_TABLE+%2B+"+where"+%2B+EMPLOYEE_HAS_ACTIVE_STATUS;

private+static+final+String+GET_EMPLOYEE_BY_SOMETHING_ELSE+=
++"+select"+%2B+EMPLOYEE_COLUMNS+%2B+"+from"+%2B+EMPLOYEE_TABLE+%2B+"+where"+%2B+SOMETHING_ELSE;|code-block|syntax|javascript|749886|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|19|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1A|8|@]|9|@]|A|$W|X]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

<h2>Re Is cut-and-past ever acceptable:</h2>

Yes. When the segment is slightly different and you're doing disposable systems ( systems that are there for a very short amount of time and won't need maintenance ). Otherwise, its usually better to extract the commonalities out.

<h2>Re segments that look a like but not exactly alike:</h2>

If the difference is in the data, refactor by extracting the function and using the difference in data as parameters (If there are too many to data to pass as a parameter, consider grouping them into an object or structure). 
If the difference is in some process in the function, refactor by using command pattern or abstract template. If it's still hard to refactor even with these design patterns, then your function might be trying to handle to many responsibilities on its own.

For example, if you have a code segment that differs in two segments - diff#1, and diff#2. And in diff#1, you can have diff1A, or diff1B, and for diff#2 you can have diff2A and diff2B. 

If diff1A &amp; diff2A are always together, and diff1B &amp; diff2B are always together, then diff1A &amp; diff2A can be contained in one command class or one abstract template implementation, and diff1B &amp; diff2B in another.

However, if there are several combination ( i.e. diff1A &amp; diff2A, diff1A &amp; diff2B, diff1B &amp; diff2A, diff1B &amp; diff2B ), then you may want to rethink your function because it may be trying to handle too many responsibilities on its own.

<h2>Re SQL statements:</h2>

Using logics (if-else, loops ) to build your SQL dynamically sacrifices readability. But creating all SQL variations would be hard to maintain. So meet half-way and use SQL Segments. 
Extract commonalities out as SQL segments and create all SQL variations with those SQL segments as constants. 

For example:

<pre><code>private static final String EMPLOYEE_COLUMNS = " id, fName, lName, status";

private static final String EMPLOYEE_TABLE = " employee";

private static final String EMPLOYEE_HAS_ACTIVE_STATUS = " employee";

private static final String GET_EMPLOYEE_BY_STATUS =
 " select" + EMPLOYEE_COLUMNS + " from" + EMPLOYEE_TABLE + " where" + EMPLOYEE_HAS_ACTIVE_STATUS;

private static final String GET_EMPLOYEE_BY_SOMETHING_ELSE =
 " select" + EMPLOYEE_COLUMNS + " from" + EMPLOYEE_TABLE + " where" + SOMETHING_ELSE;
</code></pre>

blocks|key|1966157|text|正如马丁·福勒所言，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1966158|就做一次，好吧。|1966159|再做两次，就开始发臭了。|1966160|三次，是时候去重构了。|offset|length|1966161|编辑:在回答评论时，这个建议的来源是唐·罗伯茨：|1966162|三次打击你就可以重构了。|1966163|Martin在重构中描述了第2章，第三条规则(第58页)。|style|BOLD|1966164|entityMap|0|LINK|mutability|MUTABLE|url|http://www.refactoring.com/^0|0|0|0|7|2|0|0|0|0|7|2|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$H|13|I|14|1|15]]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@$H|19|I|1A|P|Q]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

As Martin Fowler suggests,

do it once, fine.

do it twice, starts to smell.

do it thrice, time to <a href="http://www.refactoring.com/" rel="nofollow noreferrer">refactor</a>.

<hr>

EDIT: in answer to the comment, the origin of the advice is Don Roberts:

Three strikes and you refactor.

Martin Fowler describes that in Refactoring chapter 2, section The Rule of Three (page 58).

blocks|key|749314|text|在我公司的代码库中，我们有大约10个左右的大型SQL语句，它们具有高度的通用性。所有的语句都有一个共同的核心，或者至少有一个只有一两个单词不同的核心。然后，您可以将这10条语句分组为3或4组，为核心添加共同的附录，同样，每个附录中可能有一两个不同的单词。无论如何，将这10个SQL语句看作是具有显著重叠的Venn图中的集合。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749315|我们选择对这些语句进行编码，以避免任何重复。因此，有一个函数(从技术上讲，是一个Java方法)来构建语句。它需要一些参数来解释共同核心中的一两个单词的差异。然后，它需要一个函子来构造附属物，当然这也是用更多的参数进行参数化，以求更小的差异，更多的函子用于更多的附属物，等等。|749316|代码很聪明，因为没有任何SQL被重复。如果您需要修改SQL中的一个子句，您只需在一个地方修改它，并且所有10个SQL语句都会相应地进行修改。|749317|但人类是很难读懂的代码。对于给定的情况，了解执行什么SQL的唯一方法是使用调试器，并在SQL完全组装之后打印出来。而找出生成子句的特定函数如何符合更大的图景是令人讨厌的。|749318|写完这篇文章之后，我常常想知道如果我们只剪切和粘贴SQL查询10次会更好。当然，如果我们这样做，对SQL的任何更改可能会发生在10个位置，但是注释可以帮助我们指向要更新的10个位置。|749319|将SQL放在一个地方可以理解的好处可能会超过裁剪和粘贴SQL的缺点。|749320|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

In my company's code base, we have a series of about 10 or so big hairy SQL statements that have a high degree of commonality. All of the statements have a common core, or at least a core that only differs by a word or two. Then, you could group the 10 statements into 3 or 4 groupings that add common appendages to the core, again with maybe one or two words different in each appendage. At any rate, think of the 10 SQL statements as sets in a Venn diagram with significant overlap.

We chose to code these statements in such as way as to avoid any duplication. So, there is a function (technically, a Java method) to build the statement. It takes some parameters that account for the word or two of difference in the common core. Then, it takes a functor for building out the appendages, which of course is also parameterized with more parameters for minor differences and more functors for more appendages, and so on.

The code is clever in that none of the SQL is ever repeated. If you ever need to modify a clause in the SQL, you modify it in just one place and all 10 SQL statements are modified accordingly.

But man is the code hard to read. About the only way to figure out what SQL is going to be executed for a given case is to step through with a debugger and print out the SQL after it has been completely assembled. And figuring out how a particular function that generates a clause fits into the bigger picture is nasty.

Since writing this, I've often wondered if we would have been better off just cutting-and-pasting the SQL query 10 times. Of course, if we did this, any change to the SQL might have to occur in 10 places, but comments could help point us to the 10 places to update.

The benefit of having the SQL understandable and all in one place would probably outweigh the disadvantages of cutting-and-pasting the SQL.

blocks|key|1965840|text|如果这是唯一的办法，那就去做吧。通常情况下(取决于语言)，您可以使用可选参数满足对同一个函数的细微更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1965841|最近，我在PHP脚本中有一个add()函数和一个编辑()函数。它们几乎都执行了相同的操作，但是of+()函数执行的是更新查询，而不是插入查询。我只是做了件事|1965842|function+add($title,+$content,+$edit+=+false)
{
++++#+...
++++$sql+=+edit+?+"UPDATE+..."+:+"INSERT+...";
++++mysql_unbuffered_query($sql);
}|code-block|syntax|javascript|1965843|做得很好不要用奇怪而复杂的方法来阻止它。|1965844|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If it is the only way to do it, then go for it. Often times (depending on the language), you can satisfy minor changes to the same function with an optional argument.

Recently, I had an add() function and an edit() function in a PHP script. They both did virtually the same thing, but the edit() function performed an UPDATE query instead of an INSERT query. I just did something like

<pre><code>function add($title, $content, $edit = false)
{
 # ...
 $sql = edit ? "UPDATE ..." : "INSERT ...";
 mysql_unbuffered_query($sql);
}
</code></pre>

Worked out great -- but there are other times when copy/paste is necessary. Don't use some weird, complicated path to prevent it.

blocks|key|749954|text|好的代码就是可重用的代码。|type|ordered-list-item|depth|inlineStyleRanges|entityRanges|data|749955|别再发明轮子了。|749956|存在示例是有原因的:帮助您学习，最好更好地编写代码。|749957|你应该复制粘贴吗？管他呢！重要的是你为什么要复制和粘贴。我不想对这里的任何人持哲学态度，但让我们实际地考虑一下：|unstyled|749958|是因为懒惰吗？“废话，我以前做过.我只改变了几个变量的名字.完成了。”|749959|如果在复制和粘贴代码之前它已经是好代码，那就没有问题了。否则，你就会因为懒惰而将糟糕的代码永久化，这会让你的生活更加艰难。|749960|是因为你不明白吗？“该死.我不明白这个函数是如何工作的，但我不知道它是否能在我的代码中工作。”有可能！这可能会在你压力很大的时候节省你的时间，因为你的最后期限是上午9点。你正盯着凌晨四点钟的红眼。|749961|当您返回到此代码时，您会理解它吗？即使你评论它？不，真的--在经历了数千行代码之后，如果您在编写代码时不了解代码所做的事情，那么您将如何理解在几个星期、几个月后返回它呢？尝试学习它，尽管所有的诱惑，否则。键入它，这将有助于将其提交到内存中。你输入的每一行，都会问自己这行在做什么，以及它对这个功能的总体目标有什么贡献。即使你没有从内部学到它，你也有机会认识它，至少在你以后回到它的时候。|749962|所以-复制和粘贴代码？好吧，如果你意识到你所做的事情的含意。否则呢？不要这样做。此外，确保您有一个副本的任何第三方代码复制和粘贴许可证。似乎是常识，但你会感到惊讶的是，有多少人没有。|749963|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|10|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|11|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|12|8|@]|9|@]|A|$]]|$1|S|3|-4|5|H|7|13|8|@]|9|@]|A|$]]]|T|$]]

<ol>
<li>Good code is reusable code. </li>
<li>Don't reinvent the wheel.</li>
<li>Examples exist for a reason: to help you learn, and ideally code better.</li>
</ol>

Should you copy and paste? Who cares! What is important is why you're copy and pasting. I'm not trying to get philosophical on anyone here, but let's think about this practically:

Is it out of laziness? "Blah blah, I've done this before... I'm only changing a few variable names.. done." 

Not a problem if it was already good code before you copied and pasted it. Otherwise, you're perpetuating crappy code out of laziness which will bite your ass down the road.

Is it because you don't understand? "Damn.. I don't understand how that function works, but I wonder if it'll work in my code.." It might! This may save you time in the immediate moment when you're stressed that you have a deadline at 9 a.m. and you're staring red eyed at a clock around 4 a.m. 

Will you understand this code when you return to it? Even if you comment it? No really - after thousands of lines of code, if you don't understand what the code is doing as you write it how will you understand coming back to it weeks, months later? Attempt to learn it, despite all temptation otherwise. Type it out, this will help commit it to memory. Each line you type, ask yourself what that line is doing and how it contributes to the overall purpose of that function. Even if you don't learn it inside out, you might have a chance at recognizing it at the very least when you return to it later on.

So - copying and pasting code? Fine if you're conscious of the implications of what you're doing. Otherwise? Don't do it. Also, make sure you have a copy of the license of any 3rd party code you copy and paste. Seems common sense, but you'd be surprised how many people don't.

blocks|key|431901|text|我避免像瘟疫一样切割和粘贴。甚至比它的表亲克隆和修改还要糟糕。如果遇到像您这样的情况，我总是准备使用宏处理器或其他脚本来生成不同的变体。在我的经验中，一个单一的真理是非常重要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431902|不幸的是，由于换行符、表达式、语句和参数的引用要求令人讨厌，C宏处理器在这方面不是很好。我讨厌写作|431903|#define+RETPOS(E)+do+{+if+((E)+>+0)+then+return;+}+while(0)|code-block|syntax|javascript|431904|但这句话是必要的。尽管C预处理器存在缺陷，但我经常使用它，因为它不向工具链添加另一项，因此不需要更改构建过程或Makefile。|431905|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I avoid cut and paste like the plague. It's even worse than its cousin clone and modify. If faced with a situation like yours I'm always ready to use a macro processor or other script to generate the different variations. In my experience a single point of truth is hugely important.

Unfortunately the C macro processor is not very good for this purpose because of the annoying quoting requirements for newlines, expressions, statements, and arguments. I hate writing

<pre><code>#define RETPOS(E) do { if ((E) &gt; 0) then return; } while(0)
</code></pre>

but that quoting is a necessity. I will often use the C preprocessor despite its deficiencies because it doesn't add another item to the toolchain and so doesn't require changing the build process or Makefiles.

blocks|key|749699|text|我很高兴这个标签是主观的，因为它当然是！这是一个过于模糊的例子，但我可以想象，如果您有足够的重复代码，您可以将这些部分抽象出来，并使不同的部分保持不同。不复制粘贴的要点是，这样您就不会有难以维护和脆弱的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|749700|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm glad this one is tagged as subjective because it certainly is! This is an overly vague example, but I would imagine that if you have enough code that is duplicated that you could abstract those sections out and keep the different parts different. The point of not copy-pasting is so you don't end up having code that is hard to maintain and fragile.

blocks|key|1965860|text|最好的方法(除了转换为通用函数或使用宏)是将注释放入其中。如果您注释代码从哪里复制到哪里，代码的共性是什么，差异，以及执行代码的原因.那你就没事了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1965861|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The best way (besides convert into common functions or use macros) is to put comments in. If you comment where the code is copied from and to, and what the commonality is, and the differences, and the reason for doing it... then you'll be ok.

blocks|key|1965978|text|如果您发现您的功能基本相同，但在不同的情况下需要稍加调整，问题在于您的设计。使用多态和组合代替标志或复制粘贴。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1965979|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you find that you have functions which are mostly the same, but in different scenarios require slight tweaks, it is your design that is the problem. Use polymorphism and composition instead of flags or copy-paste.

It's generally accepted that copy and paste programming is a bad idea, but what is the best way to handle a situation where you have two functions or blocks of code that really do need to be different in just a few ways make generalizing them extremely messy? 

What if the code is substantially the same, except for a few minor variations, but those few minor variations aren't in things that are easy to factor out through either adding a parameter, template methods, or something like that?

More generally, have you ever encountered a situation where you would admit that a little copy-and-paste coding was truly justified.

Is copy-and-paste coding ever acceptable?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

大家普遍认为，复制和粘贴编程是个坏主意，但是如果您有两个函数或代码块(实际上是做的)，那么需要通过几种不同的方式来处理这些函数或代码块的情况，这使得泛化变得非常混乱，这是最好的方法吗？如果代码在本质上是相同的，除了几个小的变化之外，但是这些小的变化并不容易通过添加参数、模板方法或类似的东西来区分呢？更一般说来，你是否曾遇到过这样一种情况:你会承认，一点点复制和粘贴编码确实是合理的。

问复制和粘贴编码是否可以接受？
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问复制和粘贴编码是否可以接受？EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问复制和粘贴编码是否可以接受？
EN