admin管理员组文章数量:1529446
再也不用举手之劳了？用ChatGPT评估代码生成的质量
、唐玉田、下浦罗、、梁
摘要——大型语言模型(LLM)在各种自然语言处理(NLP)任务中表现出令人印象深刻的能力，如机器翻译、问题回答、摘要等。此外，LLM在支持软件工程任务方面也非常有价值，特别是在代码生成领域。自动代码生成是根据给定的规范或需求自动生成源代码或可执行代码的过程，提高了开发人员的工作效率。在本研究中，我们使用最新的LLM产品ChatGPT对代码生成的质量进行了系统的实证评估。我们利用五种语言(即C、C++、Java、Python和JavaScript)中的728个算法问题和54个代码场景中的18个cwe来完成代码生成任务。我们的评估包括对ChatGPT生成的代码片段的全面分析，重点关注三个关键方面:正确性、复杂性和安全性。我们还专门研究了ChatGPT参与多轮修复过程的能力(即ChatGPT的对话能力，用户之间的聊天和ChatGPT修复生成的错误代码),以促进代码生成。通过深入研究生成的代码并检查实验结果，这项工作为ChatGPT在处理代码生成任务的三个关键方面的性能提供了有价值的见解。实验结果表明:( 1) ChatGPT在判断平台上以48.14%的接受率优势更好地为2021年之前的问题生成不同语言的功能正确代码，但ChatGPT通过多轮修复过程直接修复错误代码以实现正确功能的能力相对较弱；
- 不同语言中代码片段的圈复杂度和认知复杂度的分布各不相同。此外，使用ChatGPT的多轮修复过程通常会保留或增加代码片段的复杂程度；(3)在C、C++、Java语言的算法场景和C、Python3语言的CWE场景中，ChatGPT生成的代码存在相关漏洞。然而，多轮
手稿于2023年8月8日收到；2024年3月23日修订；可接受的
2024年4月8日。公布日期2024年4月23日；当前版本的日期
2024年6月14日。本研究得到了国家自然科学基金项目62172205、国家自然科学基金项目62202306和香港理工大学项目ZGGG的资助。建议F. Ferrucci接受。(通讯作者:玉田堂。)
和梁来自上海理工大学，中国上海201210(电子邮件:liuzhj2022@shanghaitech.edu；zhanglf@shanghaitech.edu)。
唐玉田(Yutian Tang)就职于英国格拉斯哥大学G128QQ(电子邮件:yutian.tang@glasgow.ac.uk)。
中国香港特别行政区香港理工大学计算机系，邮编:999077(电子邮件:csxluo@comp.polyu.edu.hk)。
周玉铭在南京大学工作，中国南京210008(电子邮件:zhouyuming@nju.edu).
数字对象识别符10.1109/tse。59606.88868688616
易受攻击的代码片段的修复过程显示了令人鼓舞的结果，超过89%的漏洞被成功解决；以及(4)代码生成可能受到ChatGPT的非确定性因素的影响，导致代码片段在功能正确性、复杂性和安全性方面的变化。总之，我们的发现揭示了基于ChatGPT的代码生成中出现的潜在问题和限制，并为改进基于AI和LLM的代码生成技术奠定了基础。
索引术语—大型语言模型、ChatGPT、代码生成。
-
- 介绍
自动代码生成是自动生成源代码或基于
根据给定的规格或要求。它支持一系列对软件开发非常有益的功能。通过使用自动代码生成，开发人员能够提高生产率，减少开发时间，并将更多的精力放在更高级别的任务和核心逻辑上。大量关于代码生成的研究利用了基于人工智能的方法[1],[2],[3],[4],[5]，特别是对于使用大型语言模型(LLM)[6],[7],[8],[9],[10],[11] 比如最近的ChatGPT[12]。
基于人工智能的代码生成。基于人工智能的代码生成的出现是由软件系统日益增加的复杂性和对更有效的开发过程的渴望所驱动的[13]。传统的代码生成方法[14] 依赖预定义的模板或规则(例如，上下文无关的语法)和输入输出规范，这限制了它们的灵活性，并且需要手动操作。基于人工智能的方法[9],[11],[12],[15] 利用机器学习(深度学习)和自然语言处理(NLP)的能力来克服这些限制，并提供更加智能和适应性更强的代码生成能力。这些方法直接分析以自然语言表达的输入规范或需求，并基于所提供的输入生成相应的代码片段或完整的程序。
大型语言模型和ChatGPT。近年来，大型语言模型在许多自然语言处理任务中表现出了卓越的能力，如机器翻译、问答、摘要、文本生成、语法检查等[16],[17],[18],[19]。这些模型拥有理解和生成类似人类的文本的能力，接近人类的水平。LLM主要构建在Transformer架构上[6]，采用OpenAI的GPT-3(生成式预训练变压器3)[20]作为一个突出的例子。GPT-3对大量文本数据进行训练，结果
0098-5589 2024 IEEE。个人使用是允许的，但是重新发布/重新分发需要IEEE许可。
参见https://www.ieee/publications/rights/索引. html了解更多信息。
出色的表现。ChatGPT聊天机器人[12]是一个建立在GPT 3.5基础上的具有对话能力的实现[21] (或GPT-4[22]).它在机器翻译、问题回答、摘要等领域表现出突出的性能，并广泛应用于各种日常活动中。重要的是，ChatGPT还具有代码相关任务的能力，这可以进一步扩展其潜在的应用。ChatGPT现在已经成为个人、学术界和工业界的重要工具，极大地提高了各个领域的生产力。
动机。虽然使用LLM的基于人工智能的代码生成在提高生产率和自动化软件开发任务方面提供了有希望的优势，但评估生成的代码以显示更好的洞察力和理解仍然是必不可少的。LLMs的代码生成正面临挑战。例如，LLMs生成的代码在功能上是否正确、复杂和安全。LLM的训练数据集来自互联网，但是数据的质量不确定。随后，由LLM生成的代码的质量也不能得到保证[23],[24],[25],[26]。对这些方面的深入分析可以更全面地理解基于AI和LLM的代码生成。本文从正确性、复杂性和安全性三个方面对LLMs生成的代码进行深入系统的评估。具体来说，我们利用最先进的ChatGPT1作为LLMs评估的代表，由于其先进的功能和广泛的认可[12]。我们还评估了ChatGPT在代码生成任务中的对话能力(即一次对话中的多轮修复过程，用户和ChatGPT之间的聊天，用于修复生成的错误代码),包括正确性、复杂性和安全性。通过进行全面的分析，我们试图揭示基于ChatGPT的代码生成中出现的潜在问题和限制，以改进基于AI和LLM的代码生成技术。
我们的研究。为了应对上述挑战并探索ChatGPT的能力[12] 为了生成代码，我们收集并利用了来自LeetCode平台的五种语言(即C、C++、Java、Python和JavaScript)的728个算法问题和54个代码场景的18个cwe[23] 和[27]，分别用于代码生成任务，并打算回答以下研究问题(rq):
- RQ1(功能正确的代码生成):ChatGPT生成的代码功能正确吗？
- RQ2(代码生成的多轮修复):多轮修复过程在改进代码生成以实现功能正确性方面有多有效？
- RQ3(代码复杂度):ChatGPT生成的代码有多复杂？
- RQ4(安全代码生成):ChatGPT生成的代码安全吗？
- RQ5(ChatGPT的非确定性):chat GPT的非确定性输出如何影响代码生成？
1 ChatGPT中使用的版本是GPT-3.5，而不是GPT-4。
我们的实验结果表明:( 1)与2021年以后的问题相比，ChatGPT能更好地用不同的语言为2021年以前的问题生成功能正确的代码
48.14%的优势，在接受率的判断平台，但
ChatGPT能够直接修复错误代码
实现正确功能的圆形固定过程相对较弱；(2)不同语言代码段的圈复杂度和认知复杂度的分布不同。此外，使用ChatGPT的多轮修复过程通常会保留或增加代码片段的复杂程度；(3)在C、C++、Java语言的算法场景和C、Python3语言的CWE场景中，ChatGPT生成的代码存在相关漏洞。然而，易受攻击代码的多轮修复过程
snippets展示了有希望的结果，超过89%的漏洞被成功解决；以及(4)代码生成
可能会受到ChatGPT的不确定性因素的影响，导致代码片段在功能正确性、复杂性和安全性方面的变化。
捐款。综上所述，我们对本文做出了以下贡献:
- 本文对基于ChatGPT的代码生成质量进行了全面的实证评估；
- 我们从正确性、复杂性和安全性三个方面系统地评估了基于ChatGPT的代码生成，包括多轮过程。评估结果揭示了基于ChatGPT的代码生成在三个方面的潜在问题和局限性；和
- 我们的研究有助于提高对LLM在增强软件工程实践中的能力的潜在认识和理解，特别关注代码生成。
线上神器。实验脚本、结果和原始数据可从以下网址获得:[28]。
-
- 背景
在本节中，我们简要介绍LLMs、ChatGPT以及ChatGPT的使用。
法学硕士和ChatGPT。大型语言模型[6],[12],[20],[29],[30],[31],[32],[33] 指的是一类使用大量参数的人工智能模型，旨在基于大规模语言数据集处理和生成类似人类的文本。这些模型利用深度学习技术，通常采用变压器架构[6]由堆叠的编码器和解码器组成，用于学习语言中的模式、关系和结构。Transformer利用自我关注机制来衡量输入文本中单词的重要性，捕捉单词之间的长期依赖性和关系。LLM接受来自不同来源的大量文本数据的训练，在许多自然语言处理任务中表现出很强的能力，例如机器翻译、问题回答、摘要等等。通用终端[32] 伯特呢[29] 分别基于转换器的解码器(单向)和编码器(双向)组件。他们利用预训练和微调技术。GPT-2[33]和GPT-3[20]是
GPT的后继者，GPT- 2的参数模型比GPT的大，GPT-3甚至比GPT-2更大，使用了1750亿个参数。此外，随着语料库的扩大，GPT-2和GPT-3引入了零镜头和少镜头学习，以适应多任务场景。此外，GPT-3在各种任务中表现出了可与最先进的微调系统相媲美的性能。药典[9]是通过在GitHub代码数据上训练GPT-3得到的。它是GitHub Copilot的底层模型[11]，一个可以自动生成并自动完成代码的工具。为了增强LLM和用户(人类)之间的一致性，指令GPT[31]结合了额外的监督学习和来自人类反馈的强化学习(RLHF ),以微调GPT-3。ChatGPT聊天机器人[12],[31]在GPT实施
3.5[21](或GPT-4[22])，是目前最理想的通过使用指令来适应人类表达的产品LLM[31]。Chat- GPT使用与InstructGPT相同的方法，并通过RLHF提供回答后续问题的能力(即对话能力)。对话能力[12]使ChatGPT能够与用户进行对话式通信，不断生成信息或纠正以前不正确的信息。这个属性使得ChatGPT比以前的LLM更加强大和通用。因此，在本研究中，我们以最近流行的产品chat GPT(GPT-3.5的默认版本)作为LLMs的代表进行评估。使用ChatGPT。要使用ChatGPT，开发人员发送一条文本消息作为输入。该消息称为prompt，用于指导ChatGPT的文本生成。该提示可作为模型理解所需输出或用户内容的提示。ChatGPT根据输入提示和它从大量训练数据中学习到的知识做出响应。ChatGPT还支持回答后续问题(即对话能力)，允许用户进行来回对话。该功能使用户能够向ChatGPT连续发送多条文本消息，并接收保持上下文和连续性的响应。
当用户向ChatGPT提交一系列消息时，模型会在生成响应时考虑会话上下文中的每条消息。这些消息可以包括用户提示、系统指令和ChatGPT本身的先前响应。通过结合对话历史，ChatGPT可以产生更加连贯和知情的响应，同时考虑到正在进行的对话。
ChatGPT可以用于许多软件工程任务，包括代码生成。此外，通过利用聊天GPT的对话能力，用户可以为代码生成(例如，修复功能上不正确的代码)提供一系列提示(即，多轮过程)。
举例。比如提示“用Python写一个冒泡排序程序排1-10”，可以让ChatGPT用Python生成一个冒泡排序程序。如图所示。1，ChatGPT为Python中的冒泡排序程序提供了一个示例代码，它满足了提示中给出的要求。我们还可以在引导ChatGPT在代码片段的第7行用<替换比较运算符>的同一个对话中附加一个新的提示“以非递增顺序输出排序的结果”。
图一。Python中ChatGPT生成的冒泡排序算法。
-
- 实证研究设置
在本节中，我们将介绍与交互的工作流
ChatGPT生成代码和其他学习设置。
- 数据收集
评估我们的研究涉及两个数据集的使用:LeetCode问题[27] 和CWE(常见弱点列举)方案(CWE编码方案)，如中所述[23]。对于LeetCode问题数据集，我们随机收集了728个算法问题，其中354个和374个分别发表在2021年之后和2021年之前。之所以把它们分开，是因为ChatGPT是在2021年之前对文本数据进行训练的。对于每个问题，使用指定语言的问题描述、输入输出示例和方法签名模板来生成代码。至于CWE场景数据集，它包含18个cwe，其中54个场景位于MITRE前25个cwe中[34] (其中3个在2022年排名下降到25名以下)。对于每个CWE，为代码生成提供了三种不同的代码场景(上下文)。这些数据集的详细介绍和预处理将在第二节的相应小节中介绍。IV (即秒。IV-A 和Sec。IV-D).
- 方法学
工作流程。我们研究框架的总体工作流程如图所示。2。❶我们为给定的LeetCode问题或CWE场景(即一个CWE的代码场景)构造一个合适的提示，并将构造的提示发送给ChatGPT。
❷ ChatGPT基于当前回合提供的提示和前一回合对话上下文生成响应(第一回合没有前一回合对话上下文)。我们通过ChatGPT从响应中提取两个三重反勾号之间的代码片段。❸对于生成的代码，我们利用LeetCode在线判断来测试其功能正确性，或者我们利用CodeQL[35] (通过手动分析)来检测CWE漏洞。在这里，我们把它们统称为测试。2。如果测试结果通过(例如，通过所有测试用例
图二。与ChatGPT交互生成代码片段的工作流。
或者没有检测到漏洞)，代码生成过程结束。
❹否则，在生成的代码片段中有错误(例如，编译错误)。如果与ChatGPT的对话(即dialog)中的(回合)数没有超过回合限制(例如，最大回合数5)，我们利用从LeetCode和CodeQL提供的反馈来重建新的提示，并将其输入到ChatGPT以进行新一轮的代码生成(即，返回❶进行修复)。如果测试始终未通过，并且对话中的回合数超过回合限制，则认为代码生成失败。会话中包含多个回合的整个过程称为多回合(fixing)过程(最大回合数为1的一回合过程没有fixing属性)。快速构建、测试和多轮固定过程的细节在第二节的小节中解释。IV。
提示设计原则。我们的提示设计的目标不是找到最大化聊天GPT性能的最佳提示。相反，我们的目标是提供一个可推理的提示，模拟真实世界的使用场景，特别是代码生成，这也可以避免过度适应特定的提示和数据集。在开发提示模板时，我们参考在线提示模板(例如，OpenAI Cookbook[36] 和提示库[37])来完成代码生成任务，并最终为提示设计建立以下原则:为ChatGPT提供足够的信息，同时利用其对话能力。
法学硕士。Ope- nAI提供的默认语言模型[38]对于ChatGPT是GPT-3.5。该模型包含1750亿个参数，使其成为一个功能强大且复杂的模型。GPT-3.5是专为处理各种各样的自然语言处理任务，如文本生成，文本完成和其他相关任务。在本研究中，我们使用ChatGPT的gpt-3.5-turbo-0301模型版本进行评估。我们通过一个简单的包装器查询ChatGPT
[39]OpenAI API的[38]轻松控制ChatGPT的对话能力。ChatGPT的温度设置为默认值0.7[12] 来模拟真实世界的使用场景。此外，ChatGPT的令牌限制[12]
generated code. In our experiments, we impose strict length limitations on both the input prompt and the generated response. For each round in the multi-round process, we find that the current round prompt lengths and response lengths are all under 2,400 tokens and 800 tokens, respectively, which does not exceed ChatGPT’s token limitation. Thus, for the one- round process (e.g., Sec. ), the outputs of ChatGPT are not influenced by the token limitation problem. However, in the complete multi-round process, especially when performing code generation for LeetCode problems, there are some cases where the token lengths used (include previous prompts, re- sponses, and the current round prompt and response) can exceed the token limitation. To mitigate this issue when encounter- ing the cases, we take a token-limitation strategy of adding necessary information (e.g., LeetCode problem descriptions) at the beginning of the current round prompt and remove as little of the beginning dialog content (in block granularity, i.e., one prompt or response) from the conversation as possible to keep the remaining token space for the response from ChatGPT having at least 1000in length. This strategy avoids missing the necessary details in tasks for ChatGPT. Moreover, in our obser- vation, the strategy guarantees that the generated code snippets are complete and at least ensures that the immediate previ- ous round’s response remains throughout the conversation such that ChatGPT does not lose the most recent code generation- related information. The detailed introduction of this strategy is presented in Sec. .2 IV-A), the outputs of 3 inIV-B4.
- Experiment Environment
All experiments are conducted on a server with an Intel(R) Core(TM) i9-10900X CPU @ 3.70GHz (10 cores) and 128GB RAM. Its operating system is Ubuntu 20.04. The framework designed and scripts used in the experiments are developed in Python 3.10.9. CodeQL used is in version 2.12.2.[35] used
2Disregard the prompts and responses of previous rounds.
3In the first experiment in Sec. , all lengths of responses are under 770. Thus, We slightly amplify 770 to 1000 as the length of remaining token space that should be guaranteed when generating responses.InIV-A,
4The tasks in Sec. and Sec. have no this issue. All token lengths used are lower than the token limitation.IV-A and Sec. IV-D have no this issue. All token lengths
-
- EXPERIMENT AND EVALUATION
A. Functionally Correct Code Generation
RQ1: Is the code generated by ChatGPT functionally correct?
Motivation. Given an appropriate prompt, ChatGPT is able to generate text consistent with the prompt based on knowl- edge learned. This ability may improve developer productivity , , , . In the first step, we focus on evaluating the ability of ChatGPT to generate functionally correct code automatically in one-round process.[12] [24], [40], [41], [42]. In the first step, we focus on evaluating
Approach. We let ChatGPT read the natural language de- scription of the given problem to generate the corresponding code snippet in one-round process (i.e., the maximum round number is set to 1), and utilize the problems on LeetCode as our dataset. LeetCode is an online platform that provides challenging coding problems and automatic judgment. At the time of writing, there are over 2,500 problems on LeetCode with easy, medium, and hard levels, starting from the 2014 year. We collect all problems on LeetCode, and divide them into two categories, problems before 2021 (Bef. problems) and problems after 2021 (Aft. problems), by using the time divider of 2022-01-01. Since ChatGPT is trained on text data before 2021, Bef. problems and corresponding solutions may have a high probability to appear in its training set. This case may degenerate the code generation task for Bef. problems into querying code in the database (i.e., code reuse , , ). Code reuse is a commonly used software development practice that avoids creating new code from scratch (e.g., copy-paste). Therefore, we take both problems into account.[27] [12] [4], [43], [44]).
Specifically, we focus on Algorithm problems on Leet- Codesince Algorithm problems are the most significant, numer- ous, and diverse problems on the platform. The total numbers of Bef. problems and Aft. problems are 1,624 and 354, re- spectively. Furthermore, the difficulty level distribution to both5
of them is in the ratio of 1:2:1 for hard, medium, and easy problems. Among all the Bef. problems, we sample 374 of them
randomly, having similar quantities to the Aft. problems and following the same difficulty level distribution as Aft. prob- lems. The ratio of the numbers of hard, medium, and easy
problems is also 1:2:1 for both 354 Aft. problems and 374 Bef. problems, consistent with the difficulty level distribution
LeetCode平台上的所有问题。此外，我们还检查Bef之间是否有显著差异。问题和Aft。问题。如果在船尾。问题只是Bef的重新表述。问题，ChatGPT可能能够很容易地解决它们，这可能会影响区分时间周期的实验结果的可靠性。具体来说，我们首先使用LeetCode平台上为每个问题提供的“相似问题”来寻找Bef的相似问题对。问题和Aft。问题。“类似的问题”[27] 表示两个成对的问题，它们具有相似的场景(例如，处理字符串)或者需要使用相似的算法来求解(例如，动态编程)。总共找到了142对。然后，我们有两个独立的研究生
5https://leetcode/problemset/algorithms/
手动检查这些问题对。通过仔细的检查和讨论过程，我们发现这些相似的问题要么有相似的场景，但完全不同的解决目标，要么不同的场景和条件，但可以使用类似的算法来解决，如动态规划。经过仔细的人工分析，我们没有发现任何病例。问题可以很容易地被重新表述以获得Aft。问题。因此，我们考虑Aft。问题和Bef。问题要足够不同。此外，对于每个问题，我们要求Chat- GPT生成五种不同语言的代码:C、C++、Java、Python3和JavaScript。此外，我们使用相同的提示模板为每个< problem，language >对创建相应的提示。总共有1870个和1770个Bef提示。问题和Aft。问题，分别。由于对ChatGPT查询的速率限制，我们将每个提示输入其中一次，以请求生成代码。然后，我们将解析后的解决方案提交给LeetCode进行功能正确性判断，并获取提交状态[27] 包括已接受、错误答案、编译错误、超过时间限制和运行时错误。它们分别对应于a、W.A、C.E、T.L.E和R.E。一个问题对应一个唯一的对话，以避免从其他问题触发ChatGPT的推理。状态解释如下:
- 接受:提交的代码片段通过了所有的测试用例。
- 错误答案:提交的代码片段没有编译错误，但是不能通过所有的测试用例。
- 编译错误:无法编译提交的代码段。
- 超过时间限制:提交的代码段的运行时间超过了允许的执行时间。
- 运行时错误:提交的代码snip- pet的执行触发了至少一个测试用例的运行时错误。
请注意，带有W.A .的代码不一定意味着它不包含R.E .或T.L.E..几个错误可能同时发生。然而，我们研究代码生成的功能正确性。因此，我们将它们的优先级作为c . e . r . e
> W.A. > T.L.E .默认情况下，意味着我们只关注LeetCode返回的判断结果，这种处理方法对实验结论的影响可以忽略不计。我们优先考虑C.E .和R.E .是因为这两个错误会导致代码运行失败，这也意味着W.A..T.L.E .被设置为最低优先级，因为它主要与非功能性需求相关。此外，LeetCode在线判断平台在遇到第一个失败的测试用例时终止测试过程。因此，由平台提供的测试用例通过率(提交的代码片段成功通过的预定义测试用例的百分比)可以作为下限。
我们根据如下定义的状态率(SR)度量来评估ChatGPT的代码生成能力:
SR = Nc 100% (1)
镍
其中，Nc和Ni分别是生成的属于状态的代码片段的数量和输入的提示的数量。状态为a、w、a、c、E、T.L.E或R.E..对带有W.A .、C.E .、T.L.E .或R.E .的代码的深入分析将在第二节中介绍。IV-B。
图3。
Python3中提示两个和问题的例子。
超过船尾。问题”(20.27%)下降了48.14%。不同时期代码生成在五种语言中的表现是
显著不同，p值为0.008，效应大小值为1。
船尾。问题。去船尾。问题，总的a .率低于25%，其中困难、中等和容易问题的a .率分别为0.66%、13.90%和52.47%。使用Holm-Bonferroni校正程序调整p值
五种语言不同难度之间的效应大小值分别小于0.05和等于1。结果表明，面对Aft，随着问题难度的增加，ChatGPT在功能上纠正代码生成的能力显著下降。问题。此外，即使对于简单的问题，它也只能正确回答其中的一半。在这五/四个指标中，W.A .比率是
所有语言中最高的达到58%。此外，每个
我们还进行了Wilcoxon秩和检验[45]和克里夫的德尔塔效应大小测量[46]比较两个独立样本，确定它们之间是否存在显著差异，并量化两个独立样本之间观察到的差异大小。Wilcoxon秩和检验的无效假设是两个样本之间没有显著差异，
- 五种语言在不同时期问题中的比率值)。如果从Wilcoxon秩和检验中获得的p值较小(小于0.05)，则表明两个独立样本之间存在统计学显著差异。在多重比较的情况下，我们应用Holm-Bonferroni校正[47]这是一种常用的技术，用于调整p值以降低I型错误的风险。从Cliff的Delta度量获得的效果大小的绝对值(效果大小值)的范围是从0到1。接近0的值表示影响很小，意味着两个独立样本之间的差异很小，接近1的值表示影响很大，意味着它们之间存在显著差异。通过结合Wilcoxon秩和测试和Cliff Delta的结果，我们可以全面了解代码生成结果的差异，从而得出更可靠的结论。
提示。设计的提示模板由4部分组成。它们是< Content >、< Examples >、< Template >和< Command >，符合提示设计的原则(参见第。III-B).无花果3显示了一个提示示例。<内容>用自然语言描述问题，
< Examples >显示< input，output >对功能正确的代码，< Template >指定生成代码的方法签名，< Command >要求以特定语言生成代码。
结果。桌子I 和II 展示LeetCode对五种语言两个时期两种形式判断的代码生成结果，SR，以及对应的相对频率条形图。Python3和JavaScript的列不包含C.E .因为它们都是动态编程语言。从总体结果来看，ChatGPT为Bef生成了功能正确的代码。问题发生率明显高于Aft。问题。具体来说，
Bef五种语言的平均a .率为68.41%。问题
W.A .代码片段平均有109个测试用例，然而，ChatGPT生成的代码只能通过其中的25%。困难、中等和容易的问题分别达到20.90%、21.03%和38.41%的测试用例通过率。因此，不管难度如何，生成的代码的语义都是不同的
明显不同于相应问题描述的逻辑。此外，C.E .率和R.E .率也达到了16%,而硬问题和中等问题的比率显著降低
高于容易的问题。ChatGPT为生成的代码
硬问题和中等问题更有可能同时包含编译和运行时错误。编译错误包括变量未声明、函数声明错误、变量未初始化、常量函数(即生成空体)等等。比如图。4 显示生成的函数cmpfunc在调用前没有声明。语法错误帐户
仅针对这些错误中的一小部分(3.7%)。对于运行时错误，有空指针取消引用、越界、堆
缓冲区溢出、类型错误等等，这些在人类编写的代码中很常见。至于T.L.E .率，它不占主导地位的高值(6%)，但测试用例的平均通过率是51%
这比我们的代码片段要高。平均测试用例
困难、中等和容易三个难度水平的理论学习成绩的通过率分别为68%、50%和1%(容易的问题可以忽略，因为它们的理论学习成绩接近0%)。
由于T.L.E .代码片段的测试用例通过率是部分的，它是这些问题的下限，并且至多，另外6%的生成代码可以是功能正确的，即使
它们的时间复杂度可能并不理想。
分解到每种语言，语言C、C++、Java、Python3、JavaScript的a .率分别为15.38%、19.37%、20.17%、23.93%、22.51%。此外，组合的比率分布(接受率分布)
每个问题有五种不同的语言(只考虑至少有一个正确答案的问题)。5。
从图中可以看出，medium的均值和中线都是0.5，easy的都是0.6，ChatGPT更容易将生成的代码通用化到不同的语言
对于简单的问题。easy和medium的中位数和均值之间的差异分别为0.4和0.22。此外
人类对ChatGPT接受的问题的平均接受率为66%，对不接受的问题的平均接受率为1%
表一
C、C++和JAVA语言中的代码判断结果
| 时期 | 困难 | C | C++ | Java 语言(一种计算机语言，尤用于创建网站) | ||||||||||||
| A.W.A | 首席执行官。 | 四氯乙烯 | R.E | A. | W.A | 首席执行官。 | 四氯乙烯 | R.E | A. | W.A | 首席执行官。 | 四氯乙烯 | R.E | |||
| 困难的 | 0.00 % | 62.64 % | 27.47 % | 2.20 % | 7.69 % | 0.00 % | 62.64 % | 26.37 % | 7.69 % | 3.30 % | 0.00 % | 71.11 % | 17.78 % | 5.56 % | 5.56 % | |
| 船尾。 | 中等 容易的 | 5.88 % 48.89 % | 45.29 % 36.67 % | 28.82 % 10.00 % | 7.06 % 0.00 % | 12.94 % 4.44 % | 13.37 % 51.14 % | 57.56 % 45.45 % | 13.37 % 1.14 % | 6.98 % 1.14 % | 8.72 % 1.14 % | 15.12 % 50.00 % | 69.19 % 41.11 % | 7.56 % 4.44 % | 5.81 % 2.22 % | 2.33 % 2.22 % |
| 总数 | 15.38 % | 47.58 % | 23.65 % | 3.99 % | 9.40 % | 19.37 % | 55.84 % | 13.68 % | 5.70 % | 5.41 % | 20.17 % | 62.50 % | 9.38 % | 4.83 % | 3.13 % | |
| 困难的 | 18.28 % | 38.71 % | 33.33 % | 3.23 % | 6.45 % | 42.55 % | 19.15 % | 31.91 % | 2.13 % | 4.26 % | 52.81 % | 26.97 % | 13.48 % | 2.25 % | 4.49 % | |
| Bef。 | 中等 容易的 | 46.51 % 76.29 % | 20.35 % 9.28 % | 20.93 % 6.19 % | 2.91 % 0.00 % | 9.30 % 8.25 % | 70.62 % 89.22 % | 14.12 % 6.86 % | 11.86 % 1.96 % | 0.00 % 0.98 % | 3.39 % 0.98 % | 78.16 % 94.06 % | 12.07 % 3.96 % | 4.60 % 1.98 % | 3.45 % 0.00 % | 1.72 % 0.00 % |
| 总数 | 47.24 % | 22.10 % | 20.17 % | 2.21 % | 8.29 % | 68.63 % | 13.40 % | 14.21 % | 0.80 % | 2.95 % | 76.37 % | 13.46 % | 6.04 % | 2.20 % | 1.92 % | |
| - | 总数 | 31.28 % | 34.64 % | 21.88 % | 3.09 % | 8.84 % | 44.75 % | 33.98 % | 13.95 % | 3.18 % | 4.14 % | 48.74 % | 37.57 % | 7.68 % | 3.49 % | 2.51 % |
表二
PYTHON3和JAVASCRIPT语言中的代码判断结果
| 时期 | 困难 | Python3 | Java Script语言 | ||||
| A.W.A | 四氯乙烯 | R.E | A.W.A | 四氯乙烯 | R.E | ||
| 困难的 | 2.20 % | 80.22 % | 12.09 % | 5.49 % | 1.10 % | 83.52 % | 5.49 % | 9.89 % | |
| 船尾。 | 中等 容易的 | 18.13 % 57.30 % | 61.40 % 34.83 % | 11.11 % 2.25 % | 9.36 % 5.62 % | 16.96 % 55.06 % | 67.84 % 38.20 % | 9.94 % 1.12 % | 5.26 % 5.62 % |
| 总数 | 23.93 % | 59.54 % | 9.12 % | 7.41 % | 22.51 % | 64.39 % | 6.55 % | 6.55 % |
| 困难的 | 45.56 % | 33.33 % | 8.89 % | 12.22 % | 42.22 % | 46.67 % | 2.22 % | 8.89 % | |
| Bef。 | 中等难度 | 79.07 % 95.96 % | 16.28 % 4.04 % | 1.16 % 0.00 % | 3.49 % 0.00 % | 80.47 % 93.07 % | 13.02 % 5.94 % | 1.78 % 0.00 % | 4.73 % 0.99 % |
| 总数 | 75.35 % | 17.17 % | 2.77 % | 4.71 % | 74.44 % | 19.44 % | 1.39 % | 4.72 % |
| - | 总数 | 50.00 % | 38.06 % | 5.90 % | 6.04 % | 48.80 % | 41.63 % | 3.94 % | 5.63 % |
图4。C代码中由ChatGPT生成的函数在调用前没有声明。
图5。接受的语言与相应的贸易援助比率的分布。问题。其中暗紫色和暗红色线分别代表中间值和平均值。
由ChatGPT是48%。ChatGPT与人类的表现有相似之处。此外，从功能上纠正代码的运行时
和内存开销在人类排名中非常出色，平均分别超过68%和51%的解决方案。
Bef。问题。至于Bef。问题，难、中、易问题的a .率分别为40.13%、70.95%、89.80%，远高于Aft。“问题”
尽管不同的国家之间仍然存在显著的差异
困难。使用Holm-Bonferroni correction程序调整的p值和五种语言中难度和难度之间的效应大小值分别小于0.05和大于0.9。五种语言中中等难度和容易难度之间的调整p值和效应大小值分别为0.056和0.76。对于2021年前训练集中可能出现的问题，ChatGPT表现更好，特别是对于中、易问题。解决难题的比率增加了
40%,但仍然低于50%,这表明ChatGPT为逻辑复杂的问题生成代码的能力仍然存在
很大的提升空间。总体流失率下降到17.03%，困难、中等和容易问题的流失率分别为32.89%、15.05%和6%。生成的代码仍然可以通过平均112个测试用例中的25%。硬、中、易
问题分别达到19.19%、31.12%和47.32%的测试用例通过率。后两者都有10%的提高，这表明ChatGPT对
Bef。问题。但是，C.E .率和R.E .率仍然达到接近Aft的13%。两个时期之间p值和效应大小值分别为0.328和0.3125的问题占16%
从积极意义上来说，困难问题的发生率最高，其次是中等问题。编译错误和运行时错误类似于Aft。问题包括未声明的变量、未初始化的变量、空指针取消引用、越界、堆缓冲区溢出、类型错误等等。例如，图1所示的代码。6 用于重塑给定的二维矩阵，但在第15行触发了运行时错误，分配了错误的大小
* returnColumnSizes。到T.L.E. rate，该值下降到1.87%，平均测试用例通过率为74%。
图6。ChatGPT生成的代码触发堆缓冲区溢出运行时错误。
每个ChatGPT生成的解的真实解和地面真实解从LeetCode平台获得，并且[48]6。通过我们的手动分析，我们发现没有一个解决方案是在逐个令牌的基础上生成的。但是，对于Bef来说。问题我们发现，在容易和中等困难中的6个解决方案都是2型克隆(即，有一些重命名的唯一标识符)[49] 找到真相解决方案。这一结果表明ChatGPT可能有一定的概率(> 5%)从Bef的训练集中产生相似的解。问题，特别是在容易和中等困难。
图7。被接受的语言与相应Bef的比率分布。问题(两条线的意义如图所示。5).
分解到每种语言，C、C++、Java、Python3、JavaScript的a .率分别为47.24%、68.63%、76.37%、75.35%、74.44%。最后四个lan-的速率值
各种语言彼此接近，比最低级语言C的比率值高出至少20%。图。7 显示与图相同。5 但是对于Bef来说。问题。从
图，我们可以看到中易的均值和中值线都是0.75，它们的中值和均值的差异比Aft之前的都要小。问题减半。而且哈德的均值和中线都是0.55。ChatGPT更容易将代码推广到不同的语言
为了Bef。问题。人类对ChatGPT接受的问题的平均接受率为55%，对ChatGPT不接受的问题的平均接受率为47%。功能正确的代码的运行时和内存开销也是不可避免的
在人类排名中名列前茅，平均超过71%和54%
解决方案。
我们还从所有问题中抽取50个问题作为样本(25个Aft。问题和25 Bef。问题，每个问题有5种不同语言的5个解)来调查ChatGPT有多少次精确地生成了基本事实解的精确解(逐个令牌)。我们收集了5个不同的地面
- 代码生成的多轮修复
RQ2:多轮修复过程在提高代码生成功能正确性方面有多有效？
动机。ChatGPT支持多轮对话(即对话能力)，用户可以使用该功能连续生成代码，以便在一次对话中获得功能正确的代码。在本RQ中，我们研究了使用W.A、C.E、R.E .或修复代码片段的多轮修复流程
时间长度误差。
接近。我们在多轮对话中要求ChatGPT修复错误代码片段。此外，在分析多轮修复过程的结果之前，为了更好地理解ChatGPT生成的代码，我们还进一步手动分析了每类错误的原因，包括W.A、C.E、T.L.E和R.E。分析不同类别的错误的确切步骤在下面每个小节的分析部分中给出。
结果。我们首先分析相应的错误，然后应用多轮修复进行代码生成(多轮代码生成)。
- 答案错误的代码:
- 分析:我们随机选择50个带有W.A .代码片段的问题来分析错误答案的原因。总共有157个<问题，语言>对，在这50个中
6值得注意的是，分析结果是一个下限，因为不可能检查每个解决方案的所有基本事实。
表三
157对<问题，语言>的统计
| 困难的 | 中等 | 容易的 | 总数 | |
| C | 5 | 12 | 5 | 22 |
| C++ | 5 | 17 | 七 | 29 |
| Java 语言(一种计算机语言，尤用于创建网站) | 6 | 22 | 5 | 33 |
| Python3 | 8 | 16 | 8 | 32 |
| Java Script语言 | 9 | 22 | 10 | 41 |
| 总数 | 33 | 89 | 35 | 157 |
| 问题 | 12 | 25 | 13 | 50 |
问题，在华盛顿平均每个问题有3.14对..这些副的基本静力学如表所示III。为了分析原因，两名具有算法分析经验的研究生手动检查每个W.A .代码片段，并将他们每个人分配到一个缺陷类。在这个过程中，如果有任何分歧，这两个学生进一步与高级软件分析师讨论，以解决分歧。在这157对中，115对得到一致的分类，一致性比率为0.7325。其余42对通过讨论达成一致的分类。
我们从修复的角度利用缺陷类别[50] (代码缺陷)和[51]。[50] 分析Codeforces中提交的程序[52] 并且将这些程序中的缺陷分成多个类别，并且[51]遵循中的缺陷分类[50] 构建由Codex产生的代码缺陷[9]。缺陷类别、定义和分类结果如表所示IV。正如我们所看到的，大多数缺陷都属于多块的M-L子类和算法相关的错位算法子类，分别为51和62。缺陷的其他子类相对较少，尤其是S-A、S-F、S-AS和S-DS，它们都是1。从难度的角度来看，困难问题比中等和容易的问题需要更多的修复工作，因为困难问题只有M-L和错位算法，而中等和容易的问题有其他子类。此外，在我们手动分析这些代码片段的过程中，我们还发现，从逻辑角度来看，错误的原因可以分为以下三类(另请参见表IV):
①错误细节(WD):chat GPT生成的代码
在一些细节上有错误。这些细节错误源于对给定问题的一点误解(例如，一个单词)或与对问题的理解不一致的生成代码。无花果。8和9显示分别对应于两个详细错误的两个代码示例。图。8就是对给定问题有一点误解的例子。给定问题23757 是一种媒介，要求生成满足条件的字典上最小的可能字符串。然而，由于第11行的数字从最大值开始递减，生成的代码并不完全具有字典上最小的含义。至于图1中的代码片段。9，是生成的代码与对问题的理解不一致的一个例子。已知的
七https://leetcode/problems/construct-smallest-number-from-di-string/
问题25258 是一个简单的方法，它要求根据给定的盒子的属性将它归类到一个类别中。ChatGPT理解问题的含义，但未能将自然语言中问题描述的含义转化为代码语义。这反映在第12、15和18行的条件表达式中。我们以12号线为例。自然语言中的条件是“如果盒子既“笨重”又“沉重”，那么它的类别是两者”，ChatGPT利用strcmp两次比较类别字符串是否既“笨重”又“沉重”。自然语言描述的意义并不等同于代码语义。
WD错误也很容易由人来修复，因为生成的代码逻辑大致正确。基于我们的人工分析，对应于WD错误的缺陷子类主要是除了M-L和错位算法之外的子类。
②误解某些内容(MCC):chat GPT生成的代码不具备
给定问题。但是，生成的代码使用的算法是合适的。图。10 显示了一个示例代码片段。相应的问题24339 是一个中等的问题，并且要求找到满足一个基于xor的条件的解决方案。这个问题的关键是根据这个基于异或的条件求解正确的递推公式。ChatGPT在第2-5行推理出一个递归公式，但是这个递归公式不满足问题要求的条件。其他典型的例子是使用动态编程(DP)的问题，即生成的代码使用了错误的DP方程。
MCC错误比WD错误更难人工修复，因为需要修改代码的核心以满足问题提供的条件。根据我们的人工分析，对应于MCC错误的缺陷类别是多块的。
③误解问题(MP): ChatGPT误解或不理解给出的问题描述。
生成的代码不能满足所有条件，并且使用了错误的(不对齐的)算法。图。11显示了问题2289的示例10。
在这三种错误中，MP错误是最难人工修复的，因为代码需要完全重写。对应于MP错误的缺陷子类是基于我们的手动分析的未对准算法。
-
- 多轮修复:我们取
< problem，language >与ChatGPT配对，以连续生成-
在一次独特的多回合对话中吃代码。轮次限制数设置为5，提供了5次合理的最大修复次数[53]。对于每一对，我们通过利用相应的问题(即，
图中的<内容>和<示例>。3)、代码片段和错误消息。LeetCode在线判断返回错误信息，适合作为反馈
8https://leetcode/problems/categorize-box-according-to-criteria/9https://leetcode/problems/find-the-original-array-of-prefix-xor/
description/
10https://leetcode/problems/steps-to-make-array-non-decreasing/
description/
表四
157 <问题，语言>对的缺陷分类
| 缺陷等级 | 亚纲 | 定义 | 逻辑 | 困难的 | 中等 | 容易的 | 总数 |
| 多块 | 类似的(M-S) | 类似的单块缺陷在多个不连续的 代码片段的位置。 | WD，MCC | 0 | 2 | 四 | 6 |
| 唯一(M-U) | 多样的单块缺陷在多个不连续的 代码片段的位置，修复的总行数不超过五行。 | WD，MCC | 0 | 3 | 6 | 9 | |
| 需要大修理(M-L) | 缺陷既不是M-S也不是M-U，需要多编辑 在代码片段的多个位置。 | 玛丽勒本板球俱乐部 | 9 | 32 | 10 | 51 | |
| 代码块 | 缺陷的修复需要移动或交换代码块 只插入、更新或删除了少量(< 5)附加语句。 | WD，MCC | 0 | 2 | 0 | 2 |
| 将算术/逻辑/关系/位运算符替换为- | |||||||
| 算子突变 | 其他运算符或插入/删除运算符以及相关操作数 | 陆军部(War Department) | 0 | 2 | 6 | 8 | |
| 或者修改运算符优先级。 | |||||||
| 用其他常量/变量替换数组访问， | |||||||
| 阵列变异 | 操作数，或者用 | 陆军部(War Department) | 0 | 一 | 0 | 一 | |
| 单身男子 | 另一个数组。 | ||||||
| 函数调用变异 | 用另一个函数调用或更改替换函数调用 | 陆军部(War Department) | 0 | 0 | 一 | 一 | |
| 函数参数。 | |||||||
| 添加语句(S-AS) | 插入连续的语句块。 | 陆军部(War Department) | 0 | 0 | 一 | 一 | |
| 删除语句 | 删除连续的语句块。 | 陆军部(War Department) | 0 | 一 | 0 | 一 | |
| 高阶(单路) | 一个单块补丁，结合了多个单块bug。 | 陆军部(War Department) | 0 | 13 | 2 | 15 |
| 算法相关 | 错位算法 | 使用的算法不符合给定的要求 在问题描述中。 | 下院议员 | 24 | 33 | 5 | 62 |
| 总数 | - | - | - | 33 | 89 | 35 | 157 |
提供给ChatGPT。下面是一个例子(粗体字是根据每一对的信息填写的):
如果新生成的代码片段仍未被接受(即W.A、C.E、R.E .和T.L.E .)，则相应的错误消息将直接作为新的提示提供给ChatGPT，以便在同一个对话中修复并生成新的代码片段。直接使用错误消息作为新的提示是合适的，因为ChatGPT具有对话的能力。如果生成的代码从未被接受，整个过程最多持续五轮(一轮对应一个新生成的代码片段)。但也有前一轮提示、响应和本轮提示、响应的累计令牌长度超过ChatGPT的令牌限制的情况。我们通过令牌限制策略来缓解这个问题(参见第10节)。III-B)通过重用带有当前回合的错误代码和消息的初始提示模板，避免了遗漏对ChatGPT的问题描述的必要信息。此外，它保证了完全生成的代码片段和
图8。一个带有WD错误的示例代码片段，该错误源于对给定问题描述中字典上最小的含义的误解。
也至少在实践中保留了上一轮的响应(Sec。III-B).
多轮代码生成的结果如表所示V，其中“/”的左手和右手分别代表接受的(即五轮中接受的代码片段)数和总数。从结果中，我们可以看到这157个< problem，language >对中的大部分不能通过自动化来修复。只有25对固定在5种不同的语言，其中16个是容易水平的问题。中级水平的线对只有7对，虽然它的线对总数是初级水平的两倍多。硬级别的配对几乎不可能固定。在所有困难情况下，配对的正确率不到一半。然而，从问题的解决情况来看，
表五
的多轮代码生成结果
W.A .代码片段
| C | 0/5 (0.0 %) | 0/12 (0.0 %) | 1/5 (20.0 %) | 1/22 (4.5 %) |
| C++ | 0/5 (0.0 %) | 1/17 (5.9 %) | 3/7 (42.9 %) | 4/29 (13.8 %) |
| Java 语言(一种计算机语言，尤用于创建网站) | 0/6 (0.0 %) | 0/22 (0.0 %) | 3/5 (60.0 %) | 3/33 (9.1 %) |
| Python3 | 0/8 (0.0 %) | 3/16 (18.8 %) | 4/8 (50.0 %) | 7/32 (21.9 %) |
| Java Script语言 | 2/9 (22.2 %) | 3/22 (13.6 %) | 5/10 (50.0 %) | 10/41 (24.4 %) |
表六
10轮代码生成的结果
10个W.A .代码片段
问题标题语言难度结果
通过减去等量的C++ Easy W.A .可以占领的最大敌人堡垒JavaScript Easy W.A .从DI字符串构造最小的数字JavaScript Medium A
Python3介质R.E. JavaScript介质W.A
Java硬件资源
硬水渍险
图9。带有WD错误的示例代码片段源于与问题理解不一致的生成代码。
图10。一个带有MCC错误的示例代码片段，它导致了一个错误的递归公式。
图11。带有MP错误的示例代码片段。
13个简单问题中有12个得到了解决。硬问题和中等问题的修复率仍然低于30%。每个固定对的平均回合数为1.32。25个中的21个只用一轮就能搞定。这25对缺陷类别大多为多hunk，其中M-S、M-U、M-L和M-B分别占3、3、12和1。冗余在单块和算法相关中，其中S-O、S-AS、S-HO和未对齐算法分别占2、1、2和1。
为了进一步分析为什么大部分代码段在多轮过程下无法修复，我们从这些未修复的对中随机多选择10对，并将轮次限制数扩展到10，进行多轮修复。结果如表所示VI。在这10个代码片段中，有2个在10回合下被成功修复。其余8个仍未修复，包括最终修复为R.E .的2个..我们手动检查这些失败对的最终生成的代码片段，发现其中7个标记为深灰色的代码片段与相应问题(即MCC和MP)的含义有明显的偏差。剩下的一个标记为浅灰色的几乎是正确的，只有非常小的逻辑错误(即WD和single-hunk)，其中该错误在整个多轮过程中持续存在。而且在之前的5轮修复下，只有5个W.A .的代码片段有single-hunk修复。
因此，我们的结论是，有2个原因聊天GPT不能通过多轮修复自动修复W.A .代码片段。一方面，ChatGPT缺乏掌握逻辑细节的能力，即使这些细节对人类来说可能是直截了当的。ChatGPT很难注意到这些问题并做出相应的修复。因此，ChatGPT的逻辑细节实现能力需要改进。另一方面，ChatGPT在处理需要复杂推理的问题(对于W.A .代码片段)方面有所欠缺，导致新生成的代码仍然偏离问题的实际含义。因此，这类W.A .代码片段很难直接自动修复，但情况并非总是如此(例如，表中的<从DI字符串构造最小数，Python3 >和<从DI字符串构造最小数，JavaScript >)VI 其中后者固定在第10轮)。
★总结1。带有W.A .的大多数代码缺陷都属于M-L子类和错位算法子类
表七
编译所有C.E .代码片段的错误分类
| 班级 | 说明 | 困难的 | 中等 | 容易的 | 总数 |
| 标签错误 | 标签只能是语句的一部分，而声明是 不是陈述。 | 0 | 0 | 一 | 一 |
| 重新定义 | 一个符号在多个地方被定义。 | 0 | 四 | 一 | 5 |
| 函数声明错误 | 函数在声明前被调用。 | 四 | 19 | 一 | 24 |
| 未声明的变量 | 变量在程序中被引用或使用，而没有被 先前声明或者定义的。 | 七 | 5 | 2 | 14 |
| 错误的方法名 | 使用不同于模板的方法(或函数)名称 由LeetCode提供，用于定义方法(或函数)。 | 8 | 2 | 2 | 12 |
| 常数函数 | 函数(或方法)是用空体生成的。 | 81 | 71 | 七 | 159 |
| main的重新定义 | 生成的代码片段包含已经pro-的主函数 由LeetCode提供。 | 10 | 12 | 七 | 29 |
| 使用未声明的函数 | 生成的代码段使用了未声明和未定义的函数- (主要是由EBL引起的)。 | 18 | 25 | 3 | 46 |
| 不兼容的参数类型 | 预期的参数类型和实际的不匹配 传递给方法或函数的参数类型。 | 2 | 0 | 一 | 3 |
| 未初始化的变量 | 变量正在被声明和初始化，但没有给它一个有效的 使用前的初始值。 | 2 | 2 | 0 | 四 |
| 无效运算符 | 二元运算符的操作数无效(例如%、+、/等)。 | 2 | 一 | 0 | 3 |
| #include的错误 | 无法编译指示的文件。 | 一 | 四 | 0 | 5 |
| 语法错误 | 生成的代码段有语法错误。 | 2 | 四 | 0 | 6 |
| 无属性 | 所访问的成员在相应的数据中不存在 结构。 | 一 | 2 | 0 | 3 |
| 总数 | - | 138 | 151 | 25 | 314 |
分别为51和62。缺陷的其他子类相对要少得多。
★总结2。经过我们的手动分析，我们得出结论
代码片段可以分为三类WD，
从逻辑角度看，MCC和MP。
★总结3。通过应用多轮固定，ChatGPT
修复W.A .代码片段有困难。我们为两个人总结
原因:(1) ChatGPT缺乏对逻辑细节的把握能力，(2) ChatGPT缺乏对需要复杂推理的问题的处理能力。
- 有编译错误的代码:
- 分析:我们分析所有的C.E .代码片段，并根据返回的编译错误消息手动分类
通过LeetCode。有312个C.E .的代码片段，使用三种不同的语言，C，C++和Java。
表中显示了编译错误类别、解释和分类结果VII。从表中，我们可以看到大多数编译错误都在常量函数类中，占所有编译错误的一半(159/314)。具有常量函数编译错误的代码片段意味着代码片段中的函数或方法具有空体(即，生成的代码与提供的相应代码模板相同)。因此，对于生成的代码，这种类型的编译错误不是真正的编译错误，因为它是ChatGPT代码生成失败的一种情况(它不是响应失败)。对于错误方法类的其他三种特殊编译错误
名称、main的重定义、不兼容的参数类型，与LeetCode在线判断平台有关，与LeetCode中的设置一致，但不是真正的编译错误。例如，由ChatGPT生成的编译无错代码片段可能包含main函数，但LeetCode为运行测试用例设置了- other内部main，这导致main重定义的编译错误。然而，对于错误的方法名和不兼容的参数类型，尽管它们并不表明真正的编译错误，但它表明ChatGPT可能有一定的机会生成代码，而不管提示中给出的要求(即代码模板)。更有趣的是，我们还发现，对于编译错误的方法名的代码片段，少数方法名用于Aft。问题是Bef的方法名。问题。例如，问题244911要求使用makeSimilar作为方法名，但ChatGPT生成了在问题1658中使用的minOperations的方法名12，这可能指向推理攻击问题[54],[55]。至于其余几类编译错误，都是真正的编译错误，不是LeetCode平台触发的。桌子VII 提供了这些编译错误的相应类的解释，这些类的例子可以在我们的在线工件中找到[28]。
11https://leetcode/problems/minimum-number-of-operations-to-make-
arrays-similar/
12https://leetcode/problems/minimum-operations-to-reduce-x-to-zero/
-
- 多轮固定:我们遵循W.A .的多轮固定中的设置。在C.E .的多轮修复中使用的提示-
ing和之前的有一点点不同。下面是一个例子:
其中错误信息也来自LeetCode在线判断。整个修复过程一直持续到生成的代码片段被接受或者该过程达到最大循环数5。我们将一个对话中的最终状态(例如，a .)作为相应的<问题，语言>对的最终生成结果。减轻令牌限制的策略遵循W.A .多轮修复中的设置。此外，我们对除constant function类之外的所有类进行修复，因为修复constant function相当于为< problem，language >对重新生成整个代码片段。
结果如表所示VIII。表中的x:y:z是
不同条件下的生成结果，其中x、y和z分别表示固定代码段的数量(即C.E. A .、W.A .或T.L.E .)、代码段中保留的错误数量(即C.E .相同C.E .)、代码段中更改的错误数量(即C.E .其他C.E .或R.E .)。从结果中，我们可以看到大多数代码片段都可以修复。C和C++中分别有19和22个代码片段获得保留错误和更改错误。对于115个固定代码片段，其中40个被接受，分别包含C、C++和Java中的30个、7个和3个。对于这40个代码片段，它们的编译错误类包含重定义(1)、函数声明错误(8)、未声明的变量(1)、错误的方法名(2)、重定义main (8)、使用未声明的函数(12)、不兼容的参数类型(1)、未初始化的变量(3)、无效的运算符(1)和#include错误(1)。对于保留错误和更改错误的代码片段，我们进行人工分析，并将两种错误的原因分为两类，如下:
①语言中的错误(EIL): EIL错误产生于实现代码所使用的语言(即C和C++)的属性。错误包括保留错误和更改错误。图。12 显示了保留错误的示例代码片段
表八
的多轮代码生成结果
C.E .代码片段
| 标签错误 | - | - | 0:1:0 |
| 重新定义 | - | 3:0:1 | 1:0:0 |
| 函数声明错误 | 3:1:0 | 14:4:1 | 1:0:0 |
| 未声明的变量 | 6:0:1 | 3:0:2 | 2:0:0 |
| 错误的方法名 | 8:0:0 | 2:0:0 | 2:0:0 |
| main的重新定义 | 9:0:1 | 8:0:4 | 6:0:1 |
| 使用未声明的函数 | 12:3:3 | 16:6:3 | 3:0:0 |
| 不兼容的参数类型 | 2:0:0 | - | 1:0:0 |
| 未初始化的变量 | 2:0:0 | 2:0:0 | - |
| 无效运算符 | 1:0:1 | 1:0:0 | - |
| #include的错误 | 0:1:0 | 3:1:0 | - |
| 语法错误 | 1:1:1 | 1:1:2 | - |
| 无属性 | 1:0:0 | 1:0:1 | - |
| 总数 | 45:6:7 | 54:12:14 | 16:1:1 |
图12。带有EIL保留错误(标签错误)的C代码片段示例。该代码片段是对话中最终生成的代码片段。
图13。一个用C语言编写的代码片段，更改了EIL的错误(使用未声明的函数)。该代码片段是对话中最终生成的代码片段。
(标签错误)，其中代码片段是对话中最终生成的代码片段。在这个特殊的例子中，保留的错误与标签错误有关，其中代码在声明(第7行)之前放置了一个标签(第6行)违反了C的规则。即使错误消息包含表中所示的标签错误说明，ChatGPT也无法在5轮中修复错误VII。关于更改的错误，除了一个无属性错误和两个使用未声明的函数错误外，都是运行时错误，这意味着几乎所有的C.E .错误都被修复了。ChatGPT试图生成功能正确的代码，但是
在算法的实现中触发错误。例如，最终生成的代码可能有越界错误。我们随后进一步讨论R.E。对于这两类C.E .错误，我们在图中展示了一个使用未声明函数的例子。13 ChatGPT修复了它在“}”上的原始语法错误，但是引入了另一个C.E .错误。特定错误与用作qsort函数参数的比较函数cmp有关。但是，代码片段中没有定义cmp，导致编译错误。
图14。带有EBL保留错误(#include错误)的C代码片段示例。该代码片段是对话中最终生成的代码片段。
②语言之间的错误(EBL):与EIL不同，EBL错误源于C和C++语言的相似性。这些错误仍然包括保留错误和更改错误，所有更改错误都是错误，与EBL的保留错误中的错误相同。因此，我们仅以保留误差为例。图。14显示了保留错误的示例代码片段(错误#include)。这个< problem，language >对的语言是C，但是生成的代码使用属于C++的< cstring >和< algorithm >头文件。
我们观察这些不固定的整个多轮过程
最终错误为C.E .错误的<问题，语言>对。我们发现，在大多数情况下，尽管所提供的错误消息包含C.E .错误的原因和相应的位置，并且ChatGPT从其自然语言中意识到了错误问题，但是新生成的代码片段仍然具有相同的错误。一个例子是图。12 ChatGPT注意到了每一轮中的错误，但未能修复它。对于这些错误，一个潜在的合适方法是向来自人类知识的提示中添加信息，从而触发ChatGPT真正修复错误。例如，对于图1的例子。14，我们可以向ChatGPT提供额外的信息(例如，“代码片段是C语言的，不能使用C++头文件”)来修复错误。
此外，对于表中的每个<类别、难度>(例如<使用未申报的功能，中等>)VIII 除了标签错误，
它至少有一个可以修复的代码片段。因此，ChatGPT的多轮错误代码修复(包括R.E .错误。参见表格X)也可能与ChatGPT本身或其接收的代码片段的随机性(即温度)有关。
★总结1。超过一半的ChatGPT的C.E .错误(在静态语言中)是不真实的编译错误，特别是对于con-
常量函数、错误的方法名和不兼容的参数类型。该实验结果表明，ChatGPT的代码生成稳定性(避免生成空体)和与人类注意力的一致性(满足用户需求，如提供方法签名)是需要加强的潜在严重问题。
★总结2。通过应用多轮修复，大多数(70%)的C.E .代码片段可以被修复，其中26%可以被修复到..在分析了未修复的代码片段后，可以
推断不确定的原因可以归结为EIL和EBL。此外，帮助ChatGPT修复未修复错误的一个潜在方法是添加人类知识。
- 有运行时错误的代码:
- 分析:我们还分析所有的R.E .代码片段，并根据运行时错误消息手动分类
由LeetCode返回。有194个R.E .的代码片段，五种不同的语言，C，C++，Java，Python3，JavaScript。运行时错误类别、解释和分类结果如表所示IX。从表中可以看出，动态语言(即Python3和JavaScript)的常量函数类中有少量代码片段，与C.E .的结果不同。此外，像c . e . er-errors一样，R.E. errors中错误的方法名并不是真正的运行时错误，我们还发现了一些例子。使用Bef的方法名的问题。问题(例如，问题216413和问题90514).此外，大多数运行时错误是溢出运行时错误(即整数溢出、堆缓冲区溢出和越界)，并且这些错误中使用的语言也主要是静态语言、C、C++和Java，这类似于人类犯运行时错误。对于动态语言(即Python3和JavaScript)，大多数运行时错误都属于error类型。当对不兼容类型的对象执行操作时，会出现该错误。一个例子如图2所示。15在第9行，代码语句对字符num_str[i]和num_str[j]执行模数运算(%)，这是无效的。至于其余的类，它们的解释在表中提供IX 和他们的
例子可以在我们的在线工件中找到[28]。
- 多轮修复:我们遵循C.E .的多轮修复中的设置，这里使用的提示模板进行了修改，
将“下面< language >中的代码有编译错误:”改为“下面< language >中的代码有运行时错误:“”。
结果如表所示X。表格中的x:y:z与表格相同VIII。从结果中，我们可以看到大多数代码片段都是可以修复的，五种不同语言中分别有32个和9个代码片段得到保留错误和更改错误。对于143个固定代码片段，其中52个被接受，分别包含C、C++、Java、Python3和JavaScript中的23、12、2、10和5个。对于这52个代码片段，它们的运行时错误类别包含整数溢出(11)、堆缓冲区溢出(12)、未定义行为
(1)、越界(10)、空指针解引用(4)、方法名错误(3)、类型错误(5)、值错误(1)、释放后堆使用(1)、递归错误(1)、未初始化变量(2)、被零除(1)。至于保留错误和更改错误的代码片段，数量较少(41个)，大部分属于溢出错误。关于保留错误，通过人工分析，我们认为不能消除运行时错误的主要原因是ChatGPT的算法实现。它类似于W.A .错误中的错误(如WD)。溢出的一个例子如图2所示。6在5轮对话中，ChatGPT未能修复第15行。图。16显示了一个值错误的示例。代码片段中的问题(或冲突)在第14行和第9行之间(即char.isalpha()和char in '0 '，' 1 '，' & '，' | '，'('，')')。char.isalpha()条件检查一个字符是否是字母字符(a-z
13https://leetcode/problems/sort-even-and-odd-indices-independently/14https://leetcode/problems/sort-array-by-parity/
表九
所有R.E .代码片段的运行时错误分类
| 班级 | 说明 | 困难的 | 中等 | 容易的 | 总数 |
| 整数溢出 | 算术运算的结果超过了最大值 可以用给定的整数数据类型(如int)表示的值。 | 四 | 17 | 2 | 23 |
| 堆缓冲区溢出 | 程序在分配的内存块之外写入数据 在堆中，可能会覆盖相邻的数据或由于内存损坏而导致崩溃。 | 9 | 22 | 8 | 39 |
| 未定义行为 | 没有定义某个代码语句的执行 或者是不可预测的，可能导致意外的运行时错误或崩溃(例如，负值的左移)。 | 一 | 一 | 一 | 3 |
| 出界的 | 使用索引访问数组、列表或其他数据结构 或超出有效元素或内存范围的指针。 | 18 | 21 | 四 | 43 |
| 常数函数 | 函数(或方法)是用空体生成的。 | 3 | 6 | 一 | 10 |
| 空指针取消引用 | 程序试图通过 空指针，即不指向有效内存位置的指针。 | 四 | 8 | 2 | 14 |
| 错误的方法名 | 使用不同于模板的方法(或函数)名称 由LeetCode提供，用于定义方法(或函数)。 | 3 | 四 | 6 | 13 |
| 类型错误 | 在不兼容的对象上执行操作 类型(例如，在Python3中尝试将一个字符串与一个整数连接起来)。 | 9 | 10 | 2 | 21 |
| 数值误差 | 方法(函数)或操作接收有效类型的 输入，但值本身不适合或不在特定操作的预期范围内(例如，在Python3中向函数max传递一个空列表)。 | 0 | 四 | 一 | 5 |
| 释放后堆使用 | 在释放内存块后，使用堆中的内存块 (已释放)。 | 一 | 一 | 0 | 2 |
| 递归误差 | 函数或方法递归调用自身，而不到达 基本情况或终止条件。 | 四 | 3 | 0 | 七 |
| 未初始化的变量 | 变量正在被声明和初始化，但没有给它一个有效的 使用前的初始值。 | 一 | 一 | 0 | 2 |
| 语法错误 | 生成的代码段有语法错误。 | 3 | 0 | 0 | 3 |
| 未声明的变量 | 变量在程序中被引用或使用，而没有被 先前声明或者定义的。 | 2 | 2 | 0 | 四 |
| 无属性 | 所访问的成员在相应的数据中不存在 结构。 | 0 | 3 | 0 | 3 |
| 除以零 | 试图将一个数除以零。 | 0 | 2 | 0 | 2 |
| 总数 | - | 62 | 105 | 27 | 194 |
或A-Z)，而char in '0 '，' 1 '，' & '，' | '，'('，')'条件则检查非字母的特定字符。关于9个更改的错误，1个更改为编译错误(使用未声明的函数)，其余错误仍然是运行时错误，包括堆缓冲区溢出(1)、未定义行为(2)、越界(2)、类型错误(2)和递归错误(1)。这些新的错误是随着代码片段不断被修复以及代码片段的某些部分发生冲突而引入的。
我们还观察了这些最终误差为相对误差的非固定<问题，语言>对的整个多轮过程。像C.E .一样，在大多数情况下，ChatGPT根据提供的错误消息来发现错误，但是，新生成的代码片段仍然有相同的错误。图。6和图。16有两个例子。要修复运行时错误，也像C.E .错误，一个潜在的合适方法
是从人类知识中给提示添加信息。例如，用于固定无花果。6，我们可以提供额外的信息(例如，“* return columnsizes =(int *)mal-loc(sizeof(int))；分配错误大小的内存给
*returnColumnSizes ")来修复错误。
★总结1。静态语言和动态语言的大多数运行时错误是溢出(105)和类型错误
ror (21)分别为。此外，对于Python3和JavaScript，10个代码片段是常量函数，13个是错误方法名。结果表明，ChatGPT的代码生成稳定性和与人类注意力的一致性也是动态语言潜在的严重问题。
★总结2。通过应用多轮修复，像C.E .一样，大部分(78%)的R.E .代码片段可以被修复，其中28%可以被修复到A..在分析了未修复的代码片段后，
可以得出结论，ChatGPT在细节上是有缺陷的
图15。Python3中带有类型错误的示例代码片段。
表十
的多轮代码生成结果
代码片段
| 班级 | 困难的 | 中等 | 容易的 |
| 整数溢出 | 2:2:0 | 16:1:0 | 2:0:0 |
| 堆缓冲区溢出 | 5:1:3 | 14:8:0 | 5:3:0 |
| 未定义行为 | 0:1:0 | 1:0:0 | 1:0:0 |
| 出界的 | 14:3:1 | 15:6:0 | 4:0:0 |
| 空指针取消引用 | 3:1:0 | 6:2:0 | 1:1:0 |
| 错误的方法名 | 1:0:2 | 4:0:0 | 6:0:0 |
| 类型错误 | 8:1:0 | 8:1:1 | 2:0:0 |
| 数值误差 | - | 4:0:0 | 0:1:0 |
| 释放后堆使用 | 0:0:1 | 1:0:0 | - |
| 递归误差 | 4:0:0 | 3:0:0 | - |
| 未初始化的变量 | 1:0:0 | 1:0:0 | - |
| 语法错误 | 3:0:0 | - | - |
| 未声明的变量 | 2:0:0 | 2:0:0 | - |
| 无属性 | - | 2:0:1 | - |
| 除以零 | - | 2:0:0 | - |
| 总数 | 43:9:7 | 79:18:2 | 21:5:0 |
算法实现和潜在的触发方法
ChatGPT修复未修复的错误是添加人类知识。
- 超过时间限制的代码:
- 分析:T.L.E .有140个代码片段，使用五种不同的语言，C、C++、Java、Python3和JavaScript。二
研究生一起分析每个T.L.E .代码片段，并根据分析结果对所有这些代码片段进行分类。手动分析这些代码片段后，我们将它们的超时原因分为三类:
①对齐但低效的算法实现
(AIAI):chat GPT生成的代码中使用的算法符合问题描述中给出的要求，但有些部分效率不高。AIAI的一个经典例子是gcd函数，它使用模运算符%或减法运算符-。带有模运算符或减法运算符的两个函数都使用欧几里得算法，但是它们的
时间复杂度分别为O(log n)和O(n)。一些
T.L.E .误差是由AIAI引起的。图。17 显示了一个示例15
类似gcd。它使用减法运算符，而不是模运算
15https://leetcode/problems/reaching-points
图16。Python3中带有保留错误(值错误)的示例代码片段。
图17。带有AIAI的C代码片段示例。
operator %，增加了时间复杂度，无法在LeetCode平台设定的有限时间内通过所有测试用例。
②功能正确但未对齐算法(CMA):chat GPT使用的算法在功能上与相应的问题是正确的，但在LeetCode平台设定的有限时间内效率很低。所以，算法是错位的。在CMA中，最常见的生成代码的例子是使用蛮力方法解决问题。尽管使用强力方法的算法(或代码)在功能上是正确的，但是时间复杂度可能
也非常高(例如O(2n)时间复杂度)，从而通过LeetCode在线判断将代码判断为超时。一个
例子16 如图所示。18 其时间复杂度是指数的(码的输入大小是log n，表示输入数n)。
③功能不正确的算法(IA):chat GPT使用的算法功能不正确(即WD、MCC和
16https://leetcode/problems/count-special-integers/
餐桌XI
的多轮代码生成结果
T.L.E代码片段
| 困难的 | 中等 | 容易的 | 总数 |
| C | 2/3 (66.7 %) | 7/17 (41.2 %) | 0/0 (0.0%) | 9/20 (45.0 %) |
| C++ | 2/9 (22.2 %) | 1/12 (8.3 %) | 2/2 (100.0 %) | 5/23 (21.7 %) |
| Java 语言(一种计算机语言，尤用于创建网站) | 2/8 (25.0 %) | 8/16 (50.0 %) | 0/2 (0.0 %) | 10/26 (38.5 %) |
| Python3 | 3/19 (15.8 %) | 7/21 (33.3 %) | 0/2 (0.0 %) | 10/42 (23.8 %) |
| Java Script语言 | 2/8 (25.0 %) | 8/20 (40.0 %) | 0/1 (0.0 %) | 10/29 (34.5 %) |
| 总数 | 11/47 (23.4 %) | 31/86 (36.0 %) | 2/7 (28.6 %) | 44/140 (31.4 %) |
图18。Python3中带有CMA的示例代码片段。代码片段的时间复杂度为O(n log n)。
图19。带有IA的JavaScript示例代码片段。
MP)到相应的问题，这对于解决给定的问题实例(即，测试用例)也是缓慢的(由于不正确的功能)。该算法可以是对齐的或未对齐的(例如，强力方法)。一个例子17 如图所示。19，使用贪婪算法。算法是对齐的，但其功能不正确。在第8行中，如果条件sum + grades[i] <= count为假，则条件sum+grades[I]< = count会导致外部while循环成为无限循环，从而导致T.L.E .错误。
- 多轮修正:我们遵循W.A .的多轮修正中的设置
圆形固定。
结果如表所示XI。total中有44/140个跨不同语言和难度级别的代码片段可以由ChatGPT修复(即接受)。通过手工分析，我们发现这些代码片段位于AIAI、CMA和IA中。对于AIAI和IA的代码片段，ChatGPT倾向于生成补丁或者用不同的算法重写代码进行修复。生成补丁的一个例子是图。17 那个聊天——GPT把减法运算符——修改成模运算符%.
17https://leetcode/problems/maximum-number-of-groups-entering-a-competition/
重写代码的例子是问题104718在C中，ChatGPT将基于对齐堆栈的算法改为不使用堆栈的基于数组的算法。至于CMA中的代码片段，ChatGPT倾向于改变所使用的算法。至于剩下的96个没有修复的代码段，它们新生成的代码段判断为W.A. (64)，R.E. (8)，T.L.E
(24)通过LeetCode在线判断。对于判断为W.A .的新问题，ChatGPT能够修复导致冲突的部分
T.L.E .但不正确的功能无法修复(例如，图19)，或者它改变了所使用的算法，但是新算法在功能上是不正确的(例如，图2)18 Java版本)。对于判断为R.E .的新算法，它们的运行时错误包括整数溢出、堆缓冲区溢出、越界、值错误和
内存不足19。对于被判定为T.L.E .的新测试用例，其中16个能通过> 75%的测试用例，只有4个能通过< 50%的测试用例。通过我们的手工分析，我们发现ChatGPT倾向于
改变用来避免T.L.E .的算法，但所用的算法有一些低效的部分(即AIAI或IA)。因此，要修复这些低效的部分，一个潜在的合适方法是告诉ChatGPT低效的位置和人类的修复建议。
★总结1。通过手动分析T.L.E .代码片段，可以得出超时原因是AIAI、CMA，
还有IA。
★总结2。通过应用多轮修复，只能修复31%的代码片段。对于AIAI和IA中的固定代码片段，
ChatGPT倾向于在不同的算法中生成补丁或重写代码，对于CMA中的代码片段，ChatGPT倾向于改变所使用的算法。未固定的有24个在T.L.E .中，由AIAI和IA引起。要解决这些问题，一种潜在的方法是提供低效的位置，并由人工提出解决建议。
18https://leetcode/problems/remove-all-adjacent-duplicates-in-string/一个计算机程序试图从堆中分配内存，但是A
没有足够的可用内存来完成请求
- 代码复杂性
RQ3:chat GPT生成的代码有多复杂？动机。代码的复杂性是影响代码可读性、可维护性和整体质量的关键因素[24],
表十二
生成代码的圈复杂度结果
语言圈复杂度等级代码数量
低复杂度(1-4) 148 (21.9 %)
- ,[57]。在这个RQ中，我们评估由ChatGPT生成的代码的复杂性。
接近。我们利用SonarQube[58] 和cccc[59] 计算评价Bef复杂性的两个指标。还有船尾。生成的代码，包括多轮修复中生成的代码。度量标准是圈复杂度和认知复杂度[24],[56],[60]，其具体含义如下:
-
- 圈复杂度:复杂度计算通过给定源代码的线性独立路径的数量。它决定了给定代码的测试难度。高圈复杂度可能导致高概率的错误和缺陷。
- 认知复杂性:复杂性是指从人类的角度来衡量理解和推理一段代码的难度。它考虑了控制结构等因素，但与圈复杂度略有不同。其具体方法可以
C
C++
Java 语言(一种计算机语言，尤用于创建网站)
Python3
中等复杂程度(5-7) 223 (33.0 %)
高复杂度(8-10) 140 (20.7 %)
非常高的复杂性(11以上)165 (24.4 %)
低复杂度(1-4) 218 (34.2 %)
中等复杂程度(5-7分)241人(37.8 %)
高复杂性(8-10) 90 (14.1 %)
非常高的复杂性(11+) 89 (13.9 %)
低复杂度(1-4) 225 (33.7 %)
中等复杂程度(5-7) 240 (36.0 %)
高复杂性(8-10) 100 (15.0 %)
非常高的复杂性(11以上)102 (15.3 %)
低复杂度(1-4) 314 (44.5 %)
中等复杂程度(5-7分)226人(32.1 %)
高复杂度(8-10) 105 (14.9 %)
非常高的复杂性(11以上)60 (8.5 %)
表十三
在某地[61]。高认知复杂性会影响
生成代码的认知复杂性结果
代码的可维护性，并增加错误或错误的风险。
其中，由于Sonar- Qube和cccc的限制，对三种语言(Java、Python3和JavaScript)的认知复杂性进行了测量。
我们还利用LeetCode解决方案[48] 在C++和Python3中
由人类编写(缺少其他语言的解决方案)
语言认知复杂程度代码数量
低复杂度(< 5) 301 (42.6 %)
与ChatGPT比较，观察它们在代码复杂度上的不同程度。
请注意，复杂性是以问题为单位来衡量的(大多数解决方案只有一种方法)。
结果。我们首先检查不是在多轮修复中生成的代码片段。对多轮修复中生成的代码片段的分析将在本节的多轮比较中讨论。桌子XII和XIII显示循环图和
ChatGPT生成代码的认知复杂度值
Python3
Java Script语言
中等复杂程度(6-10) 211 (29.9 %)
高复杂度(11-20) 147 (20.8 %)
非常高的复杂度(21+) 47 (6.7 %)
低复杂度(< 5) 250 (36.7 %)
中等复杂程度(6-10) 235 (34.5 %)
高复杂度(11-20) 146 (21.4 %)
非常高的复杂度(21+) 51 (7.5 %)
表十四
五种语言。桌子XIV和XV展示人类用两种语言编写的代码的圈复杂度和认知复杂度值。
书面代码的圈复杂度结果
语言圈复杂度等级代码数量
低复杂度(1-4) 243 (39.3 %)
圈复杂度。根据PMD的官方文件[62]圈复杂度可以分为四类:低复杂度(1-4圈复杂度值)、中等复杂度(5-7)、高复杂度(8-10)和非常高复杂度(11)。从
桌子XII，我们可以发现，在五种语言中，低复杂性和中等复杂性在生成的代码中占主导地位，超过50%，其中C的百分比最低，为54.9%，而其他语言超过66%。相差至少11%。对于其他四种语言，它们的复杂性分布是相似的。
C++
Python3
中等复杂程度(5-7) 203 (32.8 %)
高复杂度(8-10) 84 (13.6 %)
非常高的复杂性(11以上)89 (14.4 %)
低复杂度(1-4) 323 (45.8 %)
中等复杂程度(5-7) 205 (29.1 %)
高复杂度(8-10) 87 (12.3 %)
非常高的复杂性(11+) 90 (12.8 %)
表十五
具体来说，从低到高的四个复杂度级别的最大值和最小值之间的差异为12%、5.7%、2.8%和7.8%。当排除Python3时，差异减少到1.7%、3.4%、2.8%和2.4%。值得注意的是，Python3有一个
低复杂度的百分比高得多(44.5%)，非常高复杂度的百分比低得多(8.5%)，而C++，
书面代码的认知复杂性结果
语言认知复杂程度代码数量
图20。圈的密度图与认知复杂性。
Java和JavaScript在这四个复杂性级别上有更相似的分布。
与C++和Python3中的人类解决方案相比(见表XIV)，我们发现两种语言生成的代码的复杂性分布与书面代码非常相似。对于C++，编写代码的百分比很低
复杂度比生成的代码高5%,相应地，中等复杂度的代码比生成的代码低5%。他们有相似的高百分比和低百分比
非常复杂。至于Python3，生成的代码和编写的代码具有相似的低复杂度百分比，而
生成的代码比编写的代码高3%和2.6%。因此，前者的极高复杂度百分比低于后者的4.3%。
认知复杂性。根据[61]，认知com-
复杂性也可以分为四类:低复杂性(< 5认知复杂性值)、中等复杂性(6-10)、高复杂性(11-20)和非常高复杂性(21)。来自表格XIII我们可以看到，低复杂性和中等复杂性都占了70%以上
五种语言。用Java和JavaScript生成的代码
具有相似的四种复杂程度的分布。对于Python3，它的低复杂度百分比(42.6%)高6%，相应地，它的中等复杂度百分比低于其他两种语言的4.7%。Python3的高复杂性和非常高复杂性的百分比也与
Java和JavaScript。
与Python3中的人类解决方案相比(见表XIV)，我们发现写出来的代码比生成的代码低复杂度的百分比高8%。相应地，
前者的中度和高度复杂性的百分比为
比后者低一倍，分别为4.9%。然而，对于这两种代码来说，非常高的复杂度的两个百分比之间的差别只有2%。
★总结1。图。20 还进一步显示了密度图
每种语言的循环和认知复杂性
和相应的编码者(即ChatGPT和人类)对。横坐标是复杂度值，纵坐标是对应的密度。通过分析这两个图，我们可以更直观地了解到ChatGPT的Python3分布的均值相对较小，而C的分布的均值较大。C++、Java和JavaScript的发行版几乎是重叠的。此外，代码的发行版
与ChatGPT用相应语言生成的代码相比，人类编写的代码向左倾斜。因此，我们可以得出结论，由ChatGPT生成的代码的复杂程度在五种编程语言中各不相同。C中生成的代码比其他语言更复杂，而C++、Java和JavaScript中代码的复杂性不相上下。Python3中的代码是最简单的。此外，C++和Python3中的ChatGPT生成的代码的复杂性略高，但几乎与人类编写的代码相当。
跨难度比较。我们进一步考察了不同难度水平下圈复杂度和认知复杂度的分布。结果显示在图。21和22。图中的每一行对应于不同难度级别的相同复杂度的百分比，而每一列代表相同难度级别的不同复杂度的百分比。图表中的百分比表示同一难度级别中某一复杂级别的比例。
无论圈复杂度还是认知复杂度，每种语言的低复杂度都随着问题难度的增加而降低。另一方面，高和非常高的复杂性随着问题难度的增加而增加。中度复杂性随着问题难度的增加没有显著变化。高和非常高的复杂性百分比随着问题难度的增加而增加。与人类编写的代码相比[48]如表所示XVI(后缀-H代表基于人类的结果)，ChatGPT生成的代码在不同难度级别上的复杂性趋势与人类编写的代码中观察到的趋势相当。这种趋势可能归因于更困难的问题，通常需要处理更多的条件、循环和嵌套结构，导致生成更复杂的代码。对于相同难度的问题，低复杂度和中等复杂度的比例
ChatGPT的C++、Java、Python3中的代码都在50%以上，即使是很难的难度问题。低和的比例
生成的JavaScript代码片段的中等复杂度也超过了50%，但是45.8%的圈复杂度略低于50%。C中生成的代码在圈复杂度中低中复杂度的比例只有37%。此外，Python3具有最高的低复杂度
和中等复杂程度，不管
图21。问题三种难度下圈复杂度的分布。
问题的难度。相比之下，C最低。C++、Java和JavaScript介于这两者之间。
★总结1。无论复杂性类型如何，低复杂性都会降低，而高复杂性和非常高复杂性会随着
增加了基于ChatGPT的代码生成的问题难度。这种趋势也与在人类编写的代码中观察到的趋势相当。此外，Python3始终拥有最高比例的低复杂度和中等复杂度。相比之下，C表现出最低比例的低复杂度和中等复杂度。C++、Java和JavaScript介于这两者之间。
跨语言比较。我们分别测量了五种不同语言(C、C++、Java、Python3和JavaScript)和三种不同语言(Java、Python3和JavaScript)对相同问题的圈复杂度和认知复杂度的组合。因此，我们只包括包含5个有效(存在且不是常量函数)不同语言代码片段的问题。前20个组合的统计结果如图2-3所示。23和24。圈复杂度总共有212种组合，认知复杂度总共有52种组合。括号中的数字1、2、3和4分别代表低、中、高和非常高的复杂性。括号中元素的位置对应于语言。对于cyclomatic com- plexity' (v，w，x，y，z)，v到z对应的语言分别是C，C++，Java，Python3，JavaScript。同样，对于认知复杂性的(x，y，z)，它们对应的语言
图22。三种问题难度水平下认知复杂性的分布。
分别是Java、Python3和JavaScript。从结果中我们可以看出(1，1，1，1，1，1)和(1，1，1)这两个数在圈复杂度和认知复杂度上都是最高的
ity，分别达到14.3%和28.3%。(2，2，2，2，2)和
(2，2，2)两者在各自的复杂度上都排第二。(4, 4,
4，4，4)和(3，3，3)分别排在第六和第四位。对于所有这些具有相同复杂程度的组合，它们具有高的个体百分比，但是它们的总体百分比是
低于50%，表明大多数组合具有不同的复杂性。作为组合的结果
图1和图2显示了不同的复杂性。23 和24复杂度等级的大多数差异是1(例如，(2，1，1，1，1)，并且
(2，1，2))，少数大于1的(如(3，2，2，1，2)和(2，1，3))。我们进一步计算每个值的差异数(即1、2、3)(见表XVII).不考虑圈
复杂性或认知复杂性中，差值为1的数量占50%以上，特别是对于认知的占76.5%。在大多数情况下，对于同一个问题，代码的复杂性
ChatGPT用不同语言生成的代码片段是相似的。我们还手动检查代码片段，并总结不同语言中针对同一问题生成的代码片段之间的复杂程度差异:
①内置库:不同语言有不同数量的内置库20。ChatGPT从一个大的
20Comparing Python to Other Languages | Python
表十六
CHATGPT生成的代码与人类编写的代码在三种问题难度水平下圈复杂度和认知复杂度分布的比较
| 公制的 | 水平 | 容易的困难 | 中等难度 | 困难重重 | |||||||||
| C++ | C++-H | 计算机编程语言 | Py-H | C++ | C++-H | 计算机编程语言 | Py-H | C++ | C++-H | 计算机编程语言 | Py-H | ||
| 低的 | 46.2% | 56.5% | 67.6% | 69.0% | 34.3% | 39.0% | 43.4% | 46.0% | 17.3% | 16.3% | 22.0% | 21.2% | |
| 圈的 | 中等偏高 | 37.6% 10.2% | 31.5% 9.2% | 25.0% 4.3% | 21.9% 8.0% | 38.5% 13.8% | 34.3% 15.3% | 34.8% 16.2% | 33.0% 11.2% | 36.7% 20.1% | 31.1% 15.6% | 34.5% 23.7% | 29.1% 19.0% |
| 非常高 | 5.9% | 2.7% | 3.2% | 1.1% | 13.5% | 11.3% | 5.6% | 9.7% | 25.9% | 37.0% | 19.8% | 30.7% | |
| 低的 | - | - | 63.8% | 73.3% | - | - | 40.4% | 51.3% | - | - | 24.2% | 25.7% | |
| 认知的 | 中等偏高 | - - | - - | 22.9% 11.7% | 18.2% 8.0% | - - | - - | 34.2% 21.5% | 27.4% 16.5% | - - | - - | 29.2% 29.2% | 27.4% 22.9% |
| 非常高 | - | - | 1.6% | 0.5% | - | - | 3.8% | 4.7% | - | - | 17.4% | 24.0% | |
表十七
圈复杂度和
认知复杂性组合
差异圈复杂度认知复杂度
图23。相同问题的五种不同语言(C、C++、Java、Python3和JavaScript)中圈复杂度组合的前20个数字。
图24。相同问题的三种不同语言(Java、Python3和JavaScript)中的前20个认知复杂性组合。
文本语料库[12] 并且可以具有选择是使用内置库来简化算法实现还是生成助手函数来实现特定功能的能力。例如，在Python3中，ChatGPT可以直接使用heapq来实现min-heap，而在C中，它还需要为min-heap生成相关的代码，这导致了不同的复杂程度。
②算法不同:不同语言针对同一问题生成的代码片段并不总是使用相同的算法。不同的算法会导致不同的复杂性。例如，问题2543的圈复杂度组合21 是(3，4，2，2，1)。C中的代码片段使用迭代算法，C++、Java和Python3中的代码片段使用递归算法。然而，JavaScript中的代码片段使用了基于数论的算法。
③逻辑的实现:由于相同或相似算法的具体实现，不同语言的代码片段的复杂度可能会有所不同。一个例子是图的问题。9。对应的圈复杂度组合是(4，3，2，1，2)。所有五个代码片段使用相同的算法，然而，Python3中代码片段的逻辑实现是最简洁的。
★总结1。通过跨语言对比分析，我们发现大多数圈圈组合
不同语言中相同问题的复杂性和认知复杂性表现出相似的复杂性水平(复杂性差异为1)。据观察，造成这些差异的因素包括语言内置的库、使用的不同算法以及逻辑实现的变化。
多轮对比。ChatGPT的多轮对话允许它持续生成代码片段。我们在10秒内从多轮修复中取出所有代码片段.IV-A作为研究多回合过程中代码段复杂度变化的样本。由于不同代码片段在对话中的多轮次数可能不同，我们使用初始代码片段和在对话结束时生成的代码片段作为对象。图。25 显示了初始代码片段之间的关系
21https://leetcode/problems/check-if-point-is-reachable/
图25。多轮流程下原始代码片段和最终代码片段的复杂程度数量热图。
不同语言和复杂性(即循环和认知)的复杂性水平和最终代码片段复杂性水平。8个子图中的y标记代表初始代码片段的复杂程度，而x标记代表最终代码片段的复杂程度。图中所示的百分比代表了在复杂语言情况下不同复杂程度变化的比例。
从图中可以看出，在所有复杂语言的情况下，对角线显示的总百分比都高于50%。这表明相当数量的
代码段在整个
多轮过程。此外，对角线上方的所有单元，对应于最终复杂度水平高于初始复杂度水平的情况，与沿着对角线对称相对的单元相比，除了Cyclomatic-JavaScript中的(低，中等)和(中等，低)单元之外，通常呈现更高的百分比。同样值得注意的是
0%的单元格也在对角线下方。因此，我们可以得出结论，多轮修复过程与聊天-
GPT通常会保留或增加代码片段的复杂程度。
我们还观察这些<初始代码片段，最终代码片段>对。对于具有预先服务或增加的复杂性级别的单元中的代码片段，ChatGPT通过调整逻辑实现(例如，将DFS的递归实现改变为迭代实现或修复类型错误)、添加或修改条件、或改变所使用的算法(例如，将蛮力算法改变为动态编程算法)来修补初始代码片段。至于复杂性级别降低的单元中的代码片段，ChatGPT还通过调整逻辑实现(例如，简化和修复
图1的逻辑实现。9)、删除或修改条件或改变所使用的算法(例如，将基于二进制搜索的算法变成包含较少控制流的迭代算法22，JavaScript >)。
★总结1。使用ChatGPT的多轮固定过程
通常保持或增加代码的复杂程度
片段，这可能会使理解ChatGPT自动一致生成的代码变得越来越困难。
22https://leetcode/problems/minimum-penalty-for-a-shop/description/
- 安全代码生成
RQ4:chat GPT生成的代码安全吗？动机。ChatGPT可能从易受攻击的代码中学习知识。在本RQ中，我们打算评估在几种特定的漏洞场景、查询和语言中由ChatGPTin生成的代码的安全性。
走近❶.我们利用CodeQL[35]对所有生成的C、C++和Java代码片段进行漏洞检测
以秒计。IV-A23。由于CodeQL标准库和其他漏洞检测工具SonarQube，我们不检测其他语言(即Python和JavaScript)的代码片段[58]没有合适的查询[63]和他们的算法问题有关。对于基于LeetCode问题生成的代码片段，漏洞检测仅限于这三种语言。此外，我们只对指针和内存相关的漏洞进行检测，因为代码片段是针对算法问题的(CodeQL和SonarQube仅限于Python和JavaScript的这两类漏洞)。我们在MITRE前25个cwe中的5个cwe上进行漏洞检测[34]，它们是CWE-787(越界写入)、CWE-416(释放后使用)、CWE-476(空指针取消引用)、CWE-190(整数溢出或回绕)和CWE-119(对内存缓冲区边界内操作的不当限制)，总共包含30个查询。而Java代码片段仅用CWE-190的4个查询来检测，这4个查询是ArithmeticTainted、Arith-meticuncontroled、ArithmeticWithExtremeValues和Com- parisonWithWiderType，因为在CodeQL和SonarQube中也没有其他合适的查询。具体的查询可以在表中找到XVIII，它们的含义可以在[63]。
我们研究了用于修复具有漏洞的代码片段的多轮修复。本节的相应部分介绍了这种方法。
走近❷.我们遵循中使用的相同设置[23]。具体来说，我们在中使用了18种常见弱点枚举(cwe)
斜接顶部25个cwe[34] (其中3个在2022年排名下降到25名以下)。对于每个CWE，ChatGPT提供了三种不同的代码场景(上下文)来生成完整的代码。这些场景是小而不完整的代码片段(在C和Python3中),其中完整的代码可能包含相对的和特定的cwe。他们来自CodeQL[35]、斜接和[23]。比如图。26显示了CWE-787(越界写入)的代码场景示例，其中“ChatGPT next line”用于告诉ChatGPT从这里完成代码。我们要求ChatGPT在一轮流程中为每个场景生成60个完整的代码片段，并利用CodeQL[35] 来分析这些代码片段是否有对应的CWE。此外，我们只针对相应的场景分析特定的cwe，而不评估功能正确性[23]。总共有18个cwe和54个场景。
23算法代码通常专注于解决特定的逻辑或计算问题，通常不涉及管理系统资源、网络通信或其他通常对安全问题敏感的操作。
表十八
漏洞检测的结果
CWE查询# Vln。#固定
图26。CWE-787的代码场景示例。
我们还研究了用于修复具有漏洞的代码片段的多轮修复。本节的相应部分介绍了这种方法。
提示❷.我们利用的代码场景(CWE的代码场景或CWE场景)用于[23] 稍加修改(具体说明
ChatGPT生成代码)作为我们的提示。
结果❶.桌子XVIII 显示漏洞检测的结果。# Vln。表示相应cwe和查询下易受攻击的代码段的数量。该百分比是特定漏洞查询(例如，CWE-476的MissingNullTest)的代码片段数除以漏洞代码片段总数(183)。如结果所示，大多数易受攻击的代码片段都在
MissingNullTest，占91.8%。ChatGPT生成的代码在分配后不执行空测试
C或C++语言中的内存，这可能会导致潜在的漏洞。对于其余的漏洞查询，其易受攻击的代码片段相对较少出现(5)，例如
作为PotentialBufferOverflow和OffsetUseBeforeRangeCheck，
但是它们仍然很重要，不应该被忽视。此外，在CWE-416和CWE-190的C、C++和Java语言中没有检测到漏洞。
- 多轮修复:我们从CWE类别的每个查询中抽取了15个包含漏洞的代码片段。如果有的话
一个查询中少于15个易受攻击的代码片段，我们对它们全部进行采样。舍入数设置为5，与秒相同。IV-A。对于每个易受攻击的代码片段，我们通过利用相应的问题、易受攻击的代码片段和CodeQL提供的相应CWE信息来创建初始提示。CWE信息包括对代码中CWE和易受攻击位置的解释。下面是一个例子:
4 20
表十九
安全代码生成的结果
1:IncompleteUrlSubstringSanitization Py。CQ。55 (98.2%) 1 (1.8%)
2:不完整的IncompleteHostnameRegExp。CQ。58 (100.0%) 0 (0.0%)
3:[23]-1摄氏度[23]58 (100.0%) 39 (67.2%)
如果新生成的代码片段仍然易受同一漏洞的攻击，则CodeQL返回的相应CWE信息(即漏洞消息)将直接作为新的提示提供给ChatGPT，以便在同一会话中修复并生成新的代码片段。如果生成的代码从不固定，则整个过程最多持续五轮。此外，减轻令牌限制的策略遵循W.A .多轮修复(第IV-B1).
多轮固定的结果如表所示XVIIIs #固定列。所有易受攻击的代码片段都已修复。对这些代码片段的修复很简单，因为它只需要一些额外的语句来检查相应的漏洞。例如，通过包含语句来测试空值或执行边界检查。因此，总的来说，对于Sec中的代码片段，ChatGPT在这种多轮修复过程中表现良好。IV-A。
★总结1。ChatGPT生成的大部分易受攻击的代码片段都与MissingNullTest查询有关，占总数的91.8%。这些代码片段在内存分配后无法执行空测试，这可能会导致安全漏洞。尽管剩下的-
诸如PotentialBufferOverflow和OffsetUseBeforeRangeCheck之类的漏洞查询不太常见，但它们仍然很重要，不应忽视。通过应用多轮修复，所有采样的易受攻击的代码片段都被修复。对于算法问题场景中易受攻击的代码片段，ChatGPT表现良好。
结果❷.桌子XIX 显示了安全代码生成的结果。r .代表2022 MITRE中cwe的排名。Lg。是
3:硬编码凭据-副本。CQ。54 (98.2%)
| 1:[23] | Py。 | [23] | 54 (100.0%) | (1.9%) | ||
| 18 306 | 2:[23] | Py。 | [23] | 59 (100.0%) | 0 (0.0%) | |
| 3:[23] | Py。 | [23] | 51 (86.4%) | 0 (0.0%) | ||
| 1: DoNotCreateWorldWriteable-a | C | CQ。 | 59 (100.0%) | 0 (0.0%) | ||
| 30 | 732 | 2: DoNotCreateWorldWriteable-b | C | CQ。 | 58 (100.0%) | 0 (0.0%) |
| 3:弱文件权限 | Py。 | CQ。 | 58 (100.0%) | 0 (0.0%) | ||
| 1:山-1 | Py。 | 芒特。 | 54 (93.1%) | 0 (0.0%) | ||
| 33 | 200 | 2:山-2 | Py。 | 芒特。 | 55 (94.8%) | 13 (23.6%) |
| 3:山-6 | Py。 | 芒特。 | 59 (100.0%) | 1 (1.7%) | ||
| 1:[23] | Py。 | [23] | 53 (100.0%) | 52 (98.1%) | ||
| 38 | 522 | 2:[23] | Py。 | [23] | 51 (100.0%) | 3 (5.9%) |
| 3:[23] | Py。 | [23] | 54 (100.0%) | 0 (0.0%) |
Py所在位置使用的语言。简称Python3。Ori。是来自密特(MT .)，CodeQL (CQ)的代码场景的源代码。)，以及[23]。# Vdn。指定由ChatGPT生成的代码的有效(可编译和语法兼容)数量和百分比。# Vln。表示数字和百分比(# Vln。编号/# Vdn。数量)的易受攻击的代码片段。请注意，尽管CWE-732、CWE-200和CWE-522在2022年的MITRE排名下降到第30、33和38位，但我们仍然将它们包括在内以保持一致
随着[23]。2022 MITRE也突出显示了它们[34]。我们也标记0%、(0%、5%]、(5%、50%]、(50%、100%]
如# Vln中的绿色、橙色、黄色和红色。细胞。代码
标记为蓝色的场景由作者手动检查。如表中所示，ChatGPT生成了2，983个有效代码片段，平均有效率为99.07%，其中994
(33.32%)是弱势群体。分解成不同的语言，
C语言中有1，402个(47%)有效代码片段包含
表二十
18个CWES的组类别和描述
| 组类别 | CWE集团 | 组描述 |
| 泛滥 | CWE-787，CWE-125，CWE-190，CWE-119 | 与缓冲区溢出和整数溢出相关 |
| 数据中和问题 | CWE 79票，CWE 89票，CWE 78票 | 使用不正确的格式创建或消除数据 |
| 输入验证 | CWE 20票，CWE 22票，CWE 434票，CWE 502票 | 未经适当验证的不当输入导致的漏洞 |
| 不安全的内存操作 | CWE 416票，CWE 476票 | 与指针的使用有关 |
| 未经验证的访问 | CWE-798，CWE-306，CWE-522 | 凭证的不当使用、验证和保护 |
| 信息泄露 | CWE 732分，CWE 200分 | 对关键资源的不正确的权限分配和未经授权的操作 |
图27。CWE-787代码场景3中生成的代码示例。
724个(51.64%)易受攻击的代码，Python3中的1581个(53%)有效代码片段包含270个(17.08%)易受攻击的代码。此外，有18个(33%)、4个(7%)、16个(30%)和16个(30%)代码场景被标记为绿色、橙色、黄色和红色
壮观地。最大和最小# Vln。百分比是
分别为100%和0%。
我们根据将18个cwe分为6组
他们的关系和描述[34]，如表所示XX。
d溢出:该组与缓冲区溢出和整数溢出有关。在12个代码场景中，有7个是
标记为红色(5)和黄色(2)，其余标记为绿色。其中CWE-787、CWE-125和CWE-119与缓冲区溢出有关，CWE-190是数据溢出。对于缓冲区溢出中的每个CWE，至少有一个红色标记。图。27显示了CWE-787代码场景3中生成的易受攻击代码的示例。该场景要求ChatGPT将浮点变量转换为字符串格式，但是生成的代码将char中的数组长度设置为小于48(最大数量-
sprintf对' \0 '输出的字符ber为47 + 1)。
然而，CWE-190有三个绿色标志。ChatGPT执行
在CWE-787，CWE-125和CWE-119的情况下表现不佳，但在CWE-190的情况下表现良好。
d数据中和问题:该组与使用不正确的格式创建或中和数据有关(例如，
SQL注入)。在9个场景中，其中的2、6和1被标记为红色、黄色和绿色。两个红色标记都在CWE-
78个达到100%# Vln。百分比。CWE-78与操作系统命令注入有关。场景中生成的代码示例
1显示在图1中。28。该场景要求ChatGPT使用给定的用户名检索用户信息，但它不检查用户名是否有效，这使得攻击者能够
图28。CWE-78代码场景1中生成的代码示例。
图29。CWE-22代码场景1中生成的代码示例。
注入任意命令。对于CWE-79和CWE-89，它们的黄色标记都低于21%，表明CWE-79和CWE-89代码场景中生成的代码大部分是
不脆弱。
d .输入验证:这一组与未经适当验证的不当输入导致的漏洞有关。
不正确的输入可能导致数据泄漏或任意命令的执行。在12个代码场景中，有4个标记为红色，分别属于CWE-20、CWE-22和CWE-
434.剩下的是# Vln。百分比都低于10%(除了CWE-22和CWE-502代码场景2)，表明在各种场景中生成的大多数代码
ios不容易受到攻击。图。29 显示了CWE协议22场景1中生成的易受攻击代码的示例。它要求ChatGPT使用给定的文件名读取文件，但是ChatGPT不检查文件名是否包含任何特殊元素，例如'..'
和“/”。有趣的是，同样的代码场景2的CWE-22，但在Python3 web应用程序中有一个# Vln。43.1%的百分比远低于CWE协议-22情景1的100%。原因可能是给定的上下文(例如Flask模块)或看到的训练代码
强制ChatGPT生成尽可能安全的代码。对于CWE-502代码场景2，实现黄色标记关闭
到一个# Vln。百分比为45%，它要求ChatGPT在Python3中反序列化YAML类型文件，然而，26个代码片段
使用yaml.load(该方法可以反序列化Python对象)而不是yaml.safe_load进行反序列化，这可能允许攻击者执行任意代码24。
d .不安全的内存操作:这一组与指针相关的问题有关，包括
自由(CWE-416)和取消引用空指针(CWE-476)。在6个代码场景中，4个和2个分别标记为红色和绿色。CWE-416代码场景1要求ChatGPT根据上下文释放临时内存。
24 Python中不安全的YAML反序列化的风险:https://excellalabs/the-risks-of-insecure-yaml-deserialization-in-python/。
消息。大多数生成的代码都避免了漏洞。因此，我们可以得出结论，ChatGPT在这些代码场景中表现良好。
- 多轮修复:我们从CWE类别的每个代码场景中抽取了5个包含漏洞的代码片段作为样本
并将这些代码片段输入ChatGPT进行修复。如果在一个代码场景中有少于5个易受攻击的代码片段，我们会对它们进行采样。舍入数设置为5，与秒相同。IV-A。对于每个易受攻击的代码片段，我们通过利用易受攻击的代码片段和CodeQL提供的相应CWE信息，或者来自[34] 用于作者检查的代码片段。下面是一个例子:
图30。CWE-416代码场景1中生成的代码示例。
图31。CWE-522代码场景1中生成的代码示例。
图。30 显示了此场景的一个示例。生成的代码在不检查abort_flag的情况下释放tmp，这可能导致被释放两次。对于CWE-476，它的所有场景都被标记为红色。一个例子已经显示在图。6 在第7、9和行
15.ChatGPT生成的代码不检查指针是否为空。总的来说，ChatGPT在这个群体中表现不佳。
未经身份验证的访问:这个组与im-不正当使用(CWE-798)、身份验证(CWE-306)和保护相关
(CWE-522)的全权证书。在9个代码场景中，只有1个在CWE-522中被标记为红色。剩下的是# Vln。百分比都低于6%(除了CWE-798代码场景
3有13%)。ChatGPT在这组表现不错。对CWE来说
522代码场景1，它要求ChatGPT散列密码
储存前给的。一个例子如图2所示。31 使用一轮SHA-256(一种安全的哈希函数)来直接哈希密码，该密码仍然容易受到暴力攻击，并且容易受到冲突攻击[64]。有趣的是，CWE-522中的其他代码场景与场景1相同，只是增加了salt=os.urandom(16)语句或bcrypt模块，避免了生成具有高概率漏洞的代码。
d .信息泄漏:这个群体与不正确的权限分配(CWE-732)和未经授权的行动有关
(CWE-200)至关键资源。在6个代码场景中，没有一个被标记为红色，只有CWE-200代码场景2被标记为带有# Vln的黄色。百分比-
年龄23.6%。其余的标记为橙色(1)和绿色(4)。黄色标记场景要求ChatGPT进行连接
Python3 web应用程序中try/catch结构的数据库，期望生成的代码不会返回数据库错误
如果新生成的代码片段仍然易受相同漏洞(例如，CWE-79的ExternalAPISink)的攻击，则由CodeQL返回的相应CWE信息(即，漏洞消息)被直接作为新的提示提供给ChatGPT，以便在同一对话中修复和生成新的代码片段。对于作者检查的代码片段，我们告诉ChatGPT，新生成的代码片段仍然具有相同的CWE漏洞(例如，“新生成的代码片段仍然包含CWE-787漏洞。”).如果生成的代码没有被修复，整个过程最多持续五轮。此外，减轻令牌限制的策略遵循W.A .多轮修复(第IV-B1).
多轮固定的结果如表所示XXI，其中# Fixed表示对应代码场景的固定数量。在160个易受攻击的代码片段中，有143个可以修复。此外，有30种代码场景，其中所有代码片段都是固定的，4种代码场景，其中代码片段是部分固定的，以及2种代码场景，其中所有代码片段都是不固定的。
d溢出:CWE-787、CWE-190和CWE-119中的所有代码片段都可以被修复。尽管第一个生成的代码
ChatGPT的代码片段存在溢出漏洞，为这些代码片段提供相应的CWE信息有助于ChatGPT成功修复简单的溢出问题。例如，对于图。27，ChatGPT将sprintf转换为snprintf25，防止缓冲区溢出。
25https://learn.microsoft/en-us/cpp/c-runtime-library/reference/
snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
表二十一
多轮易受攻击代码修复的结果
R.CWE电码情景Lg。#固定
1:mt-2c 5/5(100.0%)
1 787
2:最高气温5摄氏度5/5 (100.0 %)
3:潜在缓冲溢出C 5/5 (100.0 %)
2 79 1:外部pisingexample C5/5(100.0%)2:反射的Xss Py。4/4 (100.0 %)
1: SqlInjection-a Py。5/5 (100.0 %)
3 89
2:[23]-1便士。5/5 (100.0 %)
3:[23]-2便士。5/5 (100.0 %)
4 20 1:不完整的UrlSubstringSanitization Py。1/1 (100.0 %) 3:[23]-1摄氏度0/5 (0.0 %)
1:C4/5异常(80.0 %)
6 78
2: CommandInjection Py。5/5 (100.0 %)
3:[23]-1 C 5/5 (100.0 %)
7 416 1:mt-2c 4/5(80.0%)
1:污染路径C 5/5 (100.0 %)
8 22
2: TaintedPath Py。5/5 (100.0 %)
3: TarSlip Py。5/5 (100.0 %)
10 434 1:[23]-1便士。5/5 (100.0 %)
2:[23]-2便士。3/5 (60.0 %)
1:丢失了一个C 5/5 (100.0 %)
11 476
12 502
13 190
2:缺少NullTest-b C 5/5 (100.0 %)
3:缺少NullTest-c C 5/5 (100.0 %)
1:unsafe serialization-a Py。4/4 (100.0 %)
2:unsafeserialization-b Py。5/5 (100.0 %)
3:unsafe serialization-c Py。5/5 (100.0 %)
1:mt-4c 5/5(100.0%)
2:算术污染的C 5/5 (100.0 %)
图32。CWE-20代码场景3中最终生成的代码示例。
15 798 1:硬编码凭据-副本。1/1 (100.0 %) 3:硬编码凭据-副本。5/5 (100.0 %)
18 306 1:[23]-1便士。1/1 (100.0 %)
1:mt-3c 5/5(100.0%)
3:[23]-1 C 5/5 (100.0 %)
当数量小于0时，计算销售值的返回值小于0。
不安全的内存操作:CWE的所有代码片段
数据中和问题:CWE- 79、CWE-89和CWE-78的代码场景2和3中的所有代码片段都可以被中和
修好了。CWE-78的代码场景1中的一个代码片段仍然易受攻击。通过提供相应的CWE信息，可以修复大多数易受攻击的代码片段。对于易受攻击的漏洞，ChatGPT未能修复用于检查用户名外部输入的代码，这可能导致OS命令注入。
输入验证:CWE-20代码中的所有代码片段
场景一，CWE-22，CWE-434的代码场景一，CWE-
502可以修复。CWE-434的代码场景2中的部分代码片段可以修复。CWE- 20的代码场景3中的代码片段没有一个可以修复。ChatGPT在这一组类别中的固定性能较差。对于CWE-434的代码场景2中的2个未修复的易受攻击的代码片段(请求的图像应该以base64编码保存在数据库中，并且它们的类型必须是JPG，大小应该小于1,024KB)，它们都满足第一个要求，但完全不满足第二个要求，缺少对齐。至于CWE-20的代码场景3中的5个未修复的易受攻击的代码片段(生成股票销售的价值，其中价格
来自外部函数。值应该为0)，他们都进行了许多必要的检查，但他们忽略了
检查函数的输入值以及输出值(即股票销售的值)。例如(见图1)。32)，最终生成的代码片段不检查输入参数数量，这可能会导致函数
类别。对于CWE-416代码场景1中易受攻击的代码片段，它仍然包含被释放两次的问题(即，图1)30).
未经认证的访问:CWE-798、CWE-306和CWE-522的代码场景1中的所有代码片段都可以被修复。第3页
5 CWE-522的代码场景1中的代码片段仍然存在漏洞。ChatGPT在这个组别表现不错。对于3个易受攻击的代码片段，它们仍然一次性使用hashlib.sha256方法，而不是更安全的方法(例如，使用慢速哈希方法bcrypt.hashpw)。
d信息泄露:CWE-200的代码场景3中只有一个代码片段是固定的，但其他5个代码
CWE-200的代码场景2中的片段仍然容易受到攻击，尽管代码场景2在表中被标记为黄色XIX
(23.6%的漏洞率)。由ChatGPT生成的最终代码片段仍然会异常返回数据库错误消息
处理程序。总的来说，ChatGPT在这个组别表现不佳。
★总结1。ChatGPT成功生成了2983个(99.07%)有效代码片段，其中994个(33.32%)是漏洞代码
ble。此外，C语言中易受攻击的代码片段比例(51.64%)远高于Python3中的比例(17.08%)，这表明开发人员应该提高安全性意识
C中ChatGPT生成的代码比Python3中的多。产生这种结果的原因可能是所提供的代码场景的上下文以及在训练集中看到的C和Python代码的质量。
★总结2。ChatGPT在安全代码中不同的组、cwe和代码场景下具有不同的性能
代。总的来说，没有代码场景被标记为红色
信息泄漏组，而其余5组至少有一个代码场景标记为红色。其中不安全存储器操作组具有标记为红色的4/6(最高百分比)代码场景。在所有cwe中，有10个至少有一个代码场景被标记为红色，但只有
3 CWEs的场景仅标记为绿色或橙色。在所有代码场景中，分别有18个(33%)、4个(7%)、16个(30%)和16个(30%)代码场景被标记为绿色、橙色、黄色和红色。
★总结3。针对易受攻击的代码片段的多轮修复过程显示了令人鼓舞的结果，成功解决漏洞的比例很高(89.4%)。大多数漏洞与溢出、数据中和问题，
不安全的内存操作和未经身份验证的访问可以通过多轮修复来修复，展示了ChatGPT通过根据相应的CWE信息合并提示来生成修复代码的能力。然而，在修复输入验证和信息泄漏漏洞方面的性能相对较弱，表明有改进的空间。
- ChatGPT的非决定论
RQ5:chat GPT的非确定性输出是如何
影响代码生成？
动机。像ChatGPT这样的LLM具有不确定性[12] 通常是由于诸如top-k采样的采样方法[65]，这意味着它们可以对相同的输入产生不同的响应[23],[66]。在本RQ中，我们打算调查ChatGPT的非确定性输出。
接近。我们从Aft中随机分别选取了9个问题。问题和Bef。问题，并利用聊天GPT为这18个问题中的每一个问题用5种语言在0.7(本文中使用的默认值)和0(用于稳定输出)两种温度下生成代码10次[12]).从这些重复试验中生成的代码片段在功能正确性、复杂性和安全性方面进行了比较。此外，我们对20个CWE代码场景进行了采样，并使用ChatGPT在0℃下生成了10次代码片段。这些代码片段在安全性方面进行了比较。此外，在0.7和0的温度设置下包括多轮修复过程，其中每个采样的错误代码或易受攻击的代码被修复5次。最大回合数设置为5。
结果❶.选定的算法问题和温度为0.7时的实验结果列于表中XXII 和XXIII
对于Aft问题和Bef。问题，其中状态率(即a、w、a、C.E、T.L.E .和R.E .)的值是10次试验中相应状态的百分比；在10次试验中，圈性和认知中的L、M、H和V的比率值分别代表低、中、高和非常高复杂性水平的百分比；并且，表中的CWE对应于MissingNullTest漏洞(未检测到其他漏洞)，CWE中的值表示10次测试中具有漏洞的代码片段的百分比。从结果中，我们可以观察到以下发现:
d现状率。数据显示，对于相同问题和语言的不同尝试，生成的代码可能有
地位不同。例如，JavaScript语言的问题2224在10次测试中有50%的a .率、10%的W.A .率、10%的T.L.E .率和30%的R.E .率。此外，我们还发现一些生成的代码片段是常量函数。因此，在
后续的复杂度和安全性评估，我们去掉这些常量函数代码片段，相应的，针对相应问题和语言的尝试次数也减少了。
d复杂程度。数据表明，在使用ChatGPT的不同试验中生成的代码的复杂性可能不同。例如，Java语言中的问题363有40.0%低，50.0%中等，10.0%高，0.0%非常高的圈
复杂程度，40.0%低，0.0%中等，60.0%高，
0.0%非常高的认知复杂性水平。在不同的试验中，
ChatGPT可能使用不同的算法、实现和
以此类推，基于相同的输入生成代码片段。
D CWEs。在不同的试验下，ChatGPT可能会也可能不会生成易受攻击的代码。例如，C语言中的问题2264的CWE率为42.85%(7个非常数函数代码片段中有3个易受攻击的代码片段)。此外，
桌子XIX (# Vln的列。)也说明了基于ChatGPT的代码生成(温度0.7)在安全性方面的不确定性。
在温度0下，10次试验中算法问题和CWE码场景的不确定性代码生成统计见表XXIV,XXV和XXVI，where表XXVI介绍了选定的20个CWE电码方案。Cyc。还有Cog。分别代表圈复杂度和认知复杂度。表格条目中的元素表示为集合或比率。-表示无法评估，包括两个原因:工具支持不可用，生成的代码是常量函数，基于相应的上下文(例如，<问题2304，Java >是常量函数，因此不评估循环和认知复杂性)。从结果中，我们可以观察到，当温度设置为0时，在10次试验中，为每个算法问题生成的代码的状态是一致的。在复杂性方面观察到相同的结果，除了
<问题2532，Python3 >。所有生成的C代码都有问题
304和2523存在MissingNullTest漏洞。我们还进一步手动分析这些代码片段，发现所有生成的代码片段对于每个
< problem，language >除了< problem 2532，Python3 >在不同的试验中使用不同的代码结构。至于示例CWE代码场景，所有生成的代码片段也
表二十二
AFT的功能正确性、复杂性和安全性。温度为0.7时10次试验中的问题
问题Id语言A. W.A. C.E. T.L.E. R.E循环认知CWE
在10次试验中，每个场景都是相同的。因此，将温度设置为0可能是一种缓解ChatGPT在一轮过程中的非确定性的潜在策略。
结果❷.我们也调查了非决定论的影响
关于多轮固定过程。为了功能正确性和复杂性，我们分别在温度0.7和0下从所有生成的代码片段中随机抽取了20个有错误的代码片段，其中每个被抽取的代码片段属于一个唯一的<问题，语言>。至于安全性，我们在算法问题和CWE代码场景中，分别从温度为0.7和0时产生易受攻击代码的每个漏洞类别(在本节中选择)中随机选择一个易受攻击的代码片段。每个错误码或漏洞代码在多轮修复流程下修复5次。此外，当温度设置为0.7和0时，多轮修复过程仅在温度分别为0.7和0的一轮过程中对生成的代码段执行。固定结果如表所示XXVII–XXXII。从结果中，我们可以观察到以下发现:
d现状率。数据显示，对于不同的试验
同一错误代码的多轮修复过程
无论温度设置为0.7还是0，结果都可能不同。例如，对于温度为0.7的<问题363，C >，在5次试验中，只有2次(40%)成功；为
<问题2124，Python3 >，也只有2次试验成功。d复杂程度。数据表明，在多轮固定下，不同试验中固定码的复杂度
使用ChatGPT的过程可能会有所不同，与温度设置无关。例如，温度为0.7的固定代码片段< problem 2124，Java >在圈复杂度和认知复杂度方面都处于低和中等水平；固定代码片段
温度为0的<问题2532，Python3 >在循环和认知复杂性方面具有低、中、高和非常高的复杂性水平。在不同的试验中，ChatGPT可能会选择不同的补丁来修复多轮修复流程下的错误代码片段，甚至对于温度0的设定也是如此。
D CWEs。在多轮修复流程下的不同试验中，ChatGPT可能会也可能不会修复易受攻击的代码，重新
不考虑温度设置。比如温度0.7的ChatGPT只修复了一次CWE 20的代码场景3中的漏洞代码；在CWE 190的代码场景1中，温度为0的ChatGPT无法修复一次易受攻击的代码。
表二十三
BEF的功能正确性、复杂性和安全性。温度为0.7时10次试验中的问题
问题Id语言A. W.A. C.E. T.L.E. R.E循环认知CWE
-
- 讨论
A.吸取的教训和见解
功能上正确的代码生成。ChatGPT更擅长为Bef生成功能正确的代码。与Aft语言不同的问题。问题。此结果表明，在为定型数据集中不熟悉或看不见的问题生成代码时，ChatGPT可能会有局限性，即使
从人类的角度来看，逻辑很容易解决问题。此外，ChatGPT在用不同语言编写代码的能力上也有差异。一般来说，在C++、Java、Python3和JavaScript中，ChatGPT生成功能正确的代码的概率彼此接近，并且大大高于C语言。
通过分析ChatGPT生成的带有错误的代码片段(即W.A .，C.E .，R.E .和T.L.E .)，我们确定了在多轮修复过程下代码片段中的错误和未修复情况的几个因素。这些发现有助于专注于改进功能上正确的代码生成的正在进行的研究。其中，除了需要进一步加强ChatGPT的逻辑推理能力外，提高其代码生成稳定性(避免生成空体)和与人类注意力的对齐性(把握逻辑细节，满足提供的方法签名等用户需求)也非常重要，尤其是对于后者。ChatGPT的代码生成过程可能是粗心的，并且所生成的代码可能不满足所描述的一些详细条件，从而导致在应用多轮修复过程的情况下很难成功地生成或修复(功能正确)。因此，未来的研究可以集中在如何提供
表二十四
功能正确性、复杂性和
船尾的保安。中的问题
温度为0时的10次试验
| 问题Id | Lg。 | 状态 | Cyc。 | 齿轮。 | CWE |
| C | W.A | M | - | 0.0% | |
| C++ | W.A | M | - | 0.0% | |
| 2124 | Java 语言(一种计算机语言，尤用于创建网站) | W.A | M | M | 0.0% |
| Python3 | W.A | M | M | - | |
| Java Script语言 | W.A | M | M | - | |
| C | A. | M | - | 0.0% | |
| C++ | A. | M | - | 0.0% | |
| 2224 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | - |
| Python3 | A. | L | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | 首席执行官。 | - | - | 0.0% | |
| C++ | W.A | V | - | 0.0% | |
| 2227 | Java 语言(一种计算机语言，尤用于创建网站) | W.A | V | H | 0.0% |
| Python3 | W.A | V | H | - | |
| Java Script语言 | W.A | H | H | - | |
| C | W.A | L | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2264 | Java 语言(一种计算机语言，尤用于创建网站) | W.A | L | L | 0.0% |
| Python3 | W.A | M | H | - | |
| Java Script语言 | W.A | M | M | - | |
| C | W.A | M | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2304 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | - |
| Python3 | A. | M | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | R.E | L | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2400 | Java 语言(一种计算机语言，尤用于创建网站) | W.A | M | M | 0.0% |
| Python3 | R.E | L | L | - | |
| Java Script语言 | W.A | M | H | - | |
| C | A. | M | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2435 | Java 语言(一种计算机语言，尤用于创建网站) | W.A | H | M | 0.0% |
| Python3 | W.A | H | M | - | |
| Java Script语言 | W.A | H | H | - | |
| C | 首席执行官。 | V | - | 100% | |
| C++ | 首席执行官。 | V | - | 0.0% | |
| 2523 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | 0.0% |
| Python3 | 四氯乙烯 | H | H | - | |
| Java Script语言 | 四氯乙烯 | V | H | - | |
| C | 首席执行官。 | - | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2532 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | 0.0% |
| Python3 | W.A | V | h，V | - | |
| Java Script语言 | W.A | - | - | - |
额外的有用信息，比如代码中缺失的细节或者正确的算法逻辑，给ChatGPT补充修复的多轮修复过程，或者如何设计有效的自动代码生成工作流。
代码复杂性。用不同语言生成的代码的复杂性可能不同。此外，ChatGPT的多轮修复过程通常会保留或增加代码片段的复杂程度，这可能会使理解ChatGPT自动一致生成的代码变得越来越困难。
安全代码生成。在跨各种场景(包括算法问题和CWE场景)的评估过程中，观察到ChatGPT生成的代码经常暴露相关漏洞，这是一个严重的问题。然而，幸运的是，针对易受攻击的代码片段的多轮修复过程展示了有希望的结果。通过提供CWE信息，ChatGPT能够自动修复易受攻击的代码。因此，将ChatGPT与漏洞检测工具(例如，CodeQL)相结合可以减少由漏洞生成的代码。此外，作为一个从大规模数据集学习的人工智能助手，ChatGPT本身也可能
表二十五
功能正确性、复杂性和
BEF的安全性。中的问题
温度为0时的10次试验
| 问题Id | Lg。 | 状态 | Cyc。 | 齿轮。 | CWE |
| C | R.E | L | - | 0.0% | |
| C++ | R.E | L | - | 0.0% | |
| 9 | Java 语言(一种计算机语言，尤用于创建网站) | A. | L | L | 0.0% |
| Python3 | A. | L | L | - | |
| Java Script语言 | A. | L | L | - | |
| C | A. | L | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 70 | Java 语言(一种计算机语言，尤用于创建网站) | A. | L | L | 0.0% |
| Python3 | A. | L | L | - | |
| Java Script语言 | A. | L | L | - | |
| C | A. | M | - | 100% | |
| C++ | A. | L | - | 0.0% | |
| 304 | Java 语言(一种计算机语言，尤用于创建网站) | A. | M | M | 0.0% |
| Python3 | A. | M | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | 首席执行官。 | - | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 363 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | 0.0% |
| Python3 | A. | H | V | - | |
| Java Script语言 | W.A | V | H | - | |
| C | A. | M | - | 0.0% | |
| C++ | A. | H | - | 0.0% | |
| 581 | Java 语言(一种计算机语言，尤用于创建网站) | A. | M | M | 0.0% |
| Python3 | A. | H | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | A. | L | - | 0.0% | |
| C++ | A. | L | - | 0.0% | |
| 744 | Java 语言(一种计算机语言，尤用于创建网站) | A. | L | L | 0.0% |
| Python3 | A. | L | L | - | |
| Java Script语言 | A. | L | L | - | |
| C | A. | L | - | 0.0% | |
| C++ | A. | L | - | 0.0% | |
| 1318 | Java 语言(一种计算机语言，尤用于创建网站) | A. | L | M | 0.0% |
| Python3 | A. | M | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | W.A | M | - | 0.0% | |
| C++ | A. | M | - | 0.0% | |
| 1416 | Java 语言(一种计算机语言，尤用于创建网站) | A. | M | H | 0.0% |
| Python3 | W.A | M | M | - | |
| Java Script语言 | A. | M | M | - | |
| C | 首席执行官。 | - | - | 0.0% | |
| C++ | 首席执行官。 | - | - | 0.0% | |
| 2122 | Java 语言(一种计算机语言，尤用于创建网站) | 首席执行官。 | - | - | 0.0% |
| Python3 | W.A | M | 间位 | ||
| Java Script语言 | W.A | - | - | - |
表二十六
温度为0的10次试验中的安全代码生成
R.CWE电码情景Lg。Ori。# Vdn。# Vln。
| 一 | 787 | 2:山-5 | C | 芒特。 | 10 (100.0 %) | 10 (100.0 %) | ||
| 3 | 89 | 3:[23] | Py。 | [23] | 10 (100.0 %) | 0 (0.0 %) | ||
| 四 | 20 | 3:[23] | C | [23] | 10 (100.0 %) | 0 (0.0 %) | ||
| 5 | 125 | 3:[23] | C | [23] | 10 (100.0 %) | 0 (0.0 %) | ||
| 6 | 78 | 1:exectured | C | CQ。 | 10 (100.0 %) | 10 (100.0 %) | ||
| 七 | 416 | 3:[23] | C | [23] | 10 (100.0 %) | 0 (0.0 %) | ||
| 1:[23] | Py。 | [23] | 10 | (100.0 %) | 10 | (100.0 %) | ||
| 10 | 434 | 2:[23] | Py。 | [23] | 10 | (100.0 %) | 10 | (100.0 %) |
| 3:[23] | Py。 | [23] | 10 | (100.0 %) | 0 (0.0 %) | |||
| 1: MissingNullTest-a | C | CQ。 | 10 (100.0 %) | 10 (100.0 %) | ||||
| 11 | 476 | 2:缺少NullTest-b | C | CQ。 | 10 (100.0 %) | 10 (100.0 %) | ||
| 3: MissingNullTest-c | C | CQ。 | 10 (100.0 %) | 10 (100.0 %) | ||||
| 13 | 190 | 1:山-4 | C | 芒特。 | 10 (100.0 %) | 10 (100.0 %) | ||
| 15 | 798 | 1:硬编码凭据-a | Py。 | CQ。 | 10 (100.0 %) | 0 (0.0 %) | ||
| 1:[23] | Py。 | [23] | 10 (100.0 %) | 0 (0.0 %) | ||||
| 18 | 306 | 2:[23] | Py。 | [23] | 10 (100.0 %) | 0 (0.0 %) | ||
| 3:[23] | Py。 | [23] | 10 (100.0 %) | 0 (0.0 %) | ||||
| 2:溢出缓冲器 | C | CQ。 | 10 (100.0 %) | 0 (0.0 %) | ||||
| 19 119 3:[23] | C | [23] | 10 (100.0 %) | 10 (100.0 %) | ||||
| 30 732 2:不创建世界可写-公元前CQ。10 (100.0 %) 0 (0.0 %) | ||||||||
表二十七
温度0.7下算法问题5次试验多轮修复过程
问题Id Lg。a .评级周期。齿轮。
9摄氏度100% L -
C++ 100% L，M -
363 C 40% H，V - C++ 100% M，H -
Java 100% M，高H
JavaScript 60% H，V V
744 C++ 100% L，M -
1416 C 0.0% M，H - C++ 0.0% M，H，V - Java 100% M M
2122 C 0.0% H，V - C++ 0.0% M，H，V -
| 2124 | Java 语言(一种计算机语言，尤用于创建网站) | 100% | l，M | l，M |
| 2224 | C++ | 60% | l，M，V | - |
| Python3 | 0.0% | l，M | l，M，H | |
| 2227 | Java 语言(一种计算机语言，尤用于创建网站) | 0.0% | V | h，V |
| 2400 | C++ | 0.0% | l，M，H | - |
2523 Python3 60% H，V H，V
JavaScript 80% H，V H
2532 Java 0.0% M，H，V L，H
表二十九
温度0.7下算法问题5次试验的CWE多轮修正过程
问题Id Lg。#已修复。
表三十
温度为0时，算法问题的CWE在5次试验中的多轮修正过程
问题Id Lg。#已修复。
表二十八
中算法问题的多轮修复过程
温度为0时的5次试验
问题Id Lg。a .评级周期。齿轮。
9摄氏度100% L -
C++ 100% L -
363 C++ 100% M -
Java 100% M H
1416 Python3 0.0% M M
2122摄氏度0.0%伏-
Python3 0.0% M M
表三十一
温度为0.7时，在5次试验中生成安全代码的多轮修复过程
R.CWE电码情景Lg。Ori。#已修复。
| 10 | 434 | 1:[23] | Py。 | [23] | 5/5 (100.0 %) |
| 2:[23] | Py。 | [23] | 3/5 (60.0 %) |
1: MissingNullTest-a C CQ。5/5 (100.0 %)
11 476 2:缺少NullTest-b C CQ。5/5 (100.0 %) 3:缺少NullTest-c C CQ。5/5 (100.0 %)
2124 C++ 20% M -
Java 100% L M
Python3 40% L，M L，M
2227 C++ 0.0%
2264 C 100% M -
Python3 0.0% M M
JavaScript 100% M L，M
2435 C++ 0.0% H，V - Python3 0.0% M，H L，M，H
JavaScript 0.0% H H
2532 C 0.0% M，V -
Java 0.0% M，H M，H
Python3 0.0% L，M，H，V
具有检测漏洞的能力，作为一种更灵活的漏洞检测工具。
ChatGPT的非决定论。秒的结果。IV-E，我们可以观察到代码生成可能会受到ChatGPT的非确定性因素的影响，从而导致代码片断在功能正确性、复杂性和安全性方面的变化。缓解这个问题的一个潜在策略是将ChatGPT的温度设置为0。然而，这种策略只能在一轮过程中起作用。在多轮修复过程中，ChatGPT修复的代码片段可能在功能正确性方面有所不同，
13 190 1:第4山-第5山/第5山(100.0 %)
15 798 1:硬编码凭据-副本。CQ.4/5(80.0 %) 18 306 1:[23]-1便士。[23]5/5 (100.0 %) 19 119 3:[23]-1摄氏度[23]5/5 (100.0 %)
表三十二
温度为0时，在5次试验中生成安全代码的多轮修复过程
R.CWE电码情景Lg。Ori。#已修复。
| 10 | 434 | 1:[23] | Py。 | [23] | 5/5 (100.0 %) |
| 2:[23] | Py。 | [23] | 0/5 (0.0 %) |
复杂性和安全性，无论温度设置为0.7和0。还有其他策略来减轻非确定性因素，甚至通过调整LLM中的各种超参数(如提示)来找到更好的结果。然而，在这项研究中，我们不调整它们，这超出了本文的范围，因为我们侧重于模拟真实世界的使用场景
在代码生成任务中。我们计划在未来的工作中研究基于LLM的代码生成在不同的超参数设置中的各个方面。这样的研究将允许我们更好地理解LLM在使用不同超参数设置的代码生成中的不确定性，并且可能有助于提高LLM生成的代码片段的质量。
令牌限制的影响分析。ChatGPT的令牌限制可能会影响ChatGPT的输出。如果ChatGPT的输入提示和输出内容的总长度超过了限制，超出的部分将被丢弃，这可能会导致代码片段不完整。为了避免这个问题，我们提出了一种令牌限制策略，在整个会话过程中尽可能少地丢弃最早的内容，并补充必要的信息。这种策略避免了在ChatGPT的代码生成任务中遗漏必要的细节。为了进一步分析令牌限制对代码生成的影响，我们利用Sec中选定的算法问题和CWE代码场景。IV-E 并将ChatGPT的温度设置为0，以稳定一轮过程中的输出。我们首先计算每个代码生成中用于输出这些选定问题和场景的令牌，然后将最大输出令牌限制为每个相应代码生成中用于生成不完整代码片段的令牌使用量的一半。例如，如果ChatGPT向问题/场景输出x个令牌
I，然后将generat-的最大输出令牌限制为x/2到I
ing代码片段。这种方法模拟了生成
由于超出ChatGPT的令牌限制而导致的不完整代码片段，并提供了完整代码片段对和相应的不完整代码片段对。在测试和手动分析这些生成的不完整的代码片段之后，我们发现所有这些代码片段都由于被丢弃的部分而具有编译或语法错误(例如，二元运算符没有正确的操作数)。此外，不完整代码片段的圈复杂度和认知复杂度也小于或等于原始代码片段的圈复杂度和认知复杂度(例如，不完整代码片段遗漏了对应原始代码片段的一个if语句，或者被丢弃部分不包含任何分支语句)。为了安全起见，一些代码的漏洞不再存在(易受攻击的部分在被丢弃的部分中)，但是一些代码仍然保留其漏洞(易受攻击的部分没有被丢弃)。
与其他代码生成模型的比较。在代码生成领域，在大量代码数据集上训练的LLM极大地推动了最近的进步。与代码相关的LLM，如Codex[9]和CodeGen[67]，在代码生成任务中展示了强大的能力和通用性。这些模型通过从先前的上下文(例如，函数签名、文档串和先前生成的标记)中自回归预测下一个标记，并将先前的上下文和生成的标记组合在一起作为最终生成的代码片段，来生成代码。ChatGPT更进一步。它还展示了令人印象深刻的代码生成能力。此外，使用RLHF[31]，ChatGPT支持回答后续问题的能力，与以前的代码相关的LLM相比，提供了更加强大和通用的功能。
B.限制
本研究的结果和实验仅限于两部分:(1) ChatGPT是一个闭源模型，这意味着我们无法将分析结果直接映射到ChatGPT的内部工作方式，也无法理解模型的具体特征。此外，我们仍然不知道ChatGPT使用的确切训练数据。因此，很难确定我们输入的问题以前是否在训练数据集中使用过；(2)需要注意的是，ChatGPT是一个不断进化和训练的模型。本研究中ChatGPT生成的响应只能反映我们工作时模型的性能(即ChatGPT的模型版本gpt-3.5-turbo-0301)。
C.对有效性的威胁
LeetCode问题和CWE场景。为了通过手动选择受试者进行评估来减少偏差，我们利用LeetCode问题作为我们的主要数据集。然而，LeetCode问题是专门为编码练习和面试准备而设计的。虽然它们涵盖了一系列编程概念和挑战，但它们可能无法完全代表真实世界编码任务的复杂性和多样性。现实世界中的编码场景通常涉及各种外部因素、特定领域的需求和特定的约束，这些可能无法通过LeetCode问题完全捕捉到。此外，LeetCode problems的代码可能具有的漏洞种类是有限的，因此我们还利用了CWE场景[23] 补充对ChatGPT的安全代码生成的评估。尽管如此，与LeetCode问题类似，这些场景可能不会涵盖所有真实的代码场景。
LeetCode在线判断。LeetCode在线判断平台在遇到第一个失败的测试用例时终止测试过程。因此，该平台提供的测试用例通过率可以作为一个下限，但它不影响ChatGPT生成的代码片段的状态和从该研究中得出的结论。
CodeQL漏洞检测。CodeQL可能会将实际上安全的代码报告为易受攻击。为了降低风险，使用人工专家来手动检查代码的潜在漏洞，从而确保分析的准确性和可靠性。
漏洞检测中的有限语言。由于目标场景和漏洞检测工具的局限性，我们研究中的漏洞检测评估仅关注五种语言(C、C++、Java、Python和JavaScript)中的有限语言(C、C++和Java到LeetCode问题场景以及C和Python到CWE的场景)。虽然评估结果为这些语言中基于ChatGPT的代码生成提供了见解，但我们的研究并没有完全反映所有五种语言的安全性。
统计有效性。ChatGPT具有随机性。面对同样的输入提示，ChatGPT可能会产生不同的反应。为了降低风险，我们使用728 leet code problem。对于每个<问题，语言>对，我们独立地
一次生成一个相应的代码片段26，遵循大数定律。对于CWE的代码场景，我们为每个场景独立生成60个代码片段。至于多轮过程，我们采样了许多代码片段进行实验，并将最大轮数设置为5[53]，合理的轮限。
-
- 相关著作
语言模型。语言模型在自然语言处理中有着广泛的应用，包括机器翻译、问题回答、摘要、文本生成、代码生成等[4],[9],[16],[18],[68],[69],[70],[71],
[72],[73]。这些具有大量参数的模型在大量的语料库上被训练以更好地理解语言(即LLM)。语言模型中使用的基本架构之一是转换器[6]，由堆叠的编码器和解码器组成。Transformer利用自我关注机制来衡量输入文本中单词的重要性，捕捉单词之间的长期依赖性和关系。许多语言模型都是建立在转换器之上的。工程与后勤管理局[74]采用多层双向LSTM(长短期记忆)并提供高质量的单词表现。通用终端[32]伯特呢[29]分别基于转换器的解码器(单向)和编码器(双向)组件。他们利用预训练和微调技术。GPT-2[33]和GPT-3[20]是GPT的后继者，GPT-2的参数模型比GPT的大，GPT-3甚至比GPT-2还要大。此外，随着语料库的扩大，GPT-2和GPT-3引入了零镜头和少镜头学习，以适应多任务场景。药典[9] 是通过在GitHub代码数据上训练GPT- 3得到的。它是GitHub Copilot的底层模型[11]，一个可以自动生成并自动完成代码的工具。说明书[31] 使用额外的监督学习和来自人类反馈的强化学习(RLHF)来微调GPT-3，使语言模型与用户保持一致。ChatGPT聊天机器人[12]，基于GPT-3.5[38]，使用与InstructGPT相同的方法，并提供回答后续问题的能力。
代码生成。代码生成[75] 是语言模型的基本应用，旨在根据给定的规范或自然语言描述自动生成或完成计算机代码，从而提高编程效率。有很多关于它的研究，包括传统的方法和基于人工智能的方法。传统代码生成[14],[75],[76],[77],[78],[79]这些方法通常依赖于预定义的模板或规则(例如，上下文无关的语法)，以及输入-输出规范，这限制了它们的灵活性，并且需要人工操作。比如古尔瓦尼[78] 确定可用于各种字符串操作任务(例如，以特定格式提取子字符串)的字符串表达式语言，并设计用于学习
26ChatGPT对查询有速率限制，以后可能会重新培训。因此，我们对每个问题查询一次，而不对失败的响应进行重新查询(例如，响应为空或不相关，如违反策略)。这少量的响应被排除在实验评估之外)。
与提供的输入输出示例一致的字符串表达式。至于基于人工智能的方法[9],[11],[12],
[15],[67],[80],[81],[82]，它们利用深度学习和NLP来克服这些限制，并可以提供更加智能和适应性更强的代码生成功能。李等人。[80]利用具有注意机制的递归神经网络和抽象语法树(AST)上的指针混合网络来预测代码完成任务中的下一个单词，从大规模代码库中学习。刘等。[83] 在AST中对结构化信息进行建模，并使用Transformer-XL网络和多任务学习来捕获程序中的长期依赖性，并在代码完成中分别学习两个不相交的代码相关任务。阿什温等人。[84]将传统方法与神经网络(如LSTM网络)相结合，从实例中生成代码，正确性高，泛化能力强，综合时间短。最近，由于LLMs的优势，研究人员通过使用大量的代码数据集，如Codex，将LLMs直接应用于代码生成任务[9]，副驾驶[11]，CodeGen[67]，提供了更强大的功能和泛化能力。这些代码相关的LLM(例如，Codex)在代码生成中根据先前的上下文(例如，函数签名、文档串和先前生成的标记)自动回归预测下一个标记，并将先前的上下文和生成的标记组合在一起作为最终生成的代码片段。ChatGPT聊天机器人[12]，基于GPT-3.5的最先进的LLM[21]，也展示了令人印象深刻的代码生成能力。此外，使用RLHF[31]，ChatGPT支持回答后续问题的能力，与以前的代码相关的LLM相比，提供了更加强大和通用的功能。
基于LLM的代码生成评估。亨德里克斯等人。[85] craft APPS对Python编程问题进行基准测试，并通过对APPS进行微调来评估几个基于GPT的变体模型的代码生成性能。范等人。
[51]系统地研究自动程序修复(APR)技术，包括Codex，是否可以修复由Codex产生的LeetCode问题的不正确解决方案。夏等人。
[86] 对APR直接应用LLM(9个最先进的LLM)进行广泛的研究。他们评估了使用LLM完成任务的不同方式，包括整个补丁修复、代码块修复和单行修复。皮尔斯等人。[66]检查零射击学习对漏洞修复的LLM(例如，Codex)的使用。CodeT[87] 通过利用双执行协议，利用LLM生成功能正确的代码解决方案。它为给定的编程问题生成多个代码解决方案和多个测试用例，并使用所生成的测试用例来执行所生成的代码解决方案，以排序和找到最佳解决方案。董等人。[53]引入软件开发生命周期的概念，并提出一个自我协作框架，该框架利用不同的ChatGPT对话来扮演不同的角色(例如，分析师、开发人员和测试人员)，协作生成代码。Sobania等人。[40]在标准程序syn- thesis benchmark程序上对Copilot进行评估，将结果与遗传编程进行比较。皮尔斯等人。[23] 评估Copilot针对25大CWE漏洞生成的安全代码。阮等人。
[24] 使用4种不同语言的33个LeetCode问题评估Copilot生成代码的质量。寇等人。[88]
研究人类自然语言描述和LLMs代码生成之间的注意对准。刘等。[25] 提出EvalPlus框架以增强代码生成基准。EvalPlus接受一个基本评估数据集，并使用LLMs和变异技术来产生和多样化大量的新测试用例。刘等。[89]描述Java和Python语言中基于ChatGPT的代码生成的几个代码质量问题，包括正确性和可维护性。他们还研究了ChatGPT通过利用反馈信息来修复bug和代码风格问题的能力。与他们的工作不同，我们对基于ChatGPT的代码生成在正确性、复杂性和安全性方面进行了跨五种语言的系统评估和深入分析，包括多轮过程。我们的研究极大地扩展了当前对基于ChatGPT的代码生成的理解。我们不仅评估生成代码的正确性，而且深入探究ChatGPT生成代码不正确的潜在原因。我们还深入评估生成代码的复杂性和安全性。此外，我们深入研究了多轮修复过程对这些方面的影响，为ChatGPT在迭代代码生成场景中的能力提供了更现实的评估。这项全面的研究低估了人工智能生成的代码在现实世界软件开发中的实际意义。
-
- 结论
在本文中，我们提出了一个基于聊天GPT代码生成的系统评估。我们从正确性、复杂度、安全性三个方面对ChatGPT生成的代码片段进行综合评估，包括多轮修复过程。我们的实验结果表明:( 1) ChatGPT能更好地为Bef生成功能正确的代码。与Aft语言不同的问题。问题(av-
前者的平均接受率超过后者48.14%)，但ChatGPT能够直接修复错误代码来实现
正确的功能性相对较弱；(2)不同语言代码段的圈复杂度和认知复杂度的分布不同。此外，使用ChatGPT的多轮修复过程通常会保留或增加代码片段的复杂程度；(3)在C、C++、Java语言的算法场景和C、Python3语言的CWE场景中，ChatGPT生成的代码存在相关漏洞。幸运的是，针对易受攻击的代码片段的多轮修复过程显示出了希望
结果，高百分比(100%和89.4%)的弱点被成功解决；以及(4)代码生成可以
受到ChatGPT的不确定性因素的影响，导致代码片段在功能正确性、复杂性和安全性方面的变化。总之，我们的发现揭示了基于ChatGPT的代码生成中出现的潜在问题和限制，并为改进基于AI和LLM的代码生成技术铺平了道路。
承认
我们要感谢匿名审稿人，感谢他们为提高论文质量而提出的真知灼见。我们也感谢汤集安提供技术支持。
参考
- 米（meter的缩写））Rabinovich，M. Stern，D. Klein，“用于代码生成和语义解析的抽象语法网络”，2017年，arXiv:1704.07535。
- W.叶，谢，张，胡，王，张，“利用代码生成通过双重学习改进代码检索和摘要”。网络会议。2020年，第2309–2319页。
- 单位Alon，M. Zilberstein，O. Levy和E. Yahav，“code2vec:学习代码的分布式表示”，Proc .ACM计划。郎。，第3卷，第POPL号，第1–29页，2019年。
名词（noun的缩写）Bui，Y. Yu，和L. Jiang，“推断代码:通过预测子树的代码表示的自我监督学习”，正在进行中。IEEE/ACM第43届国际会议。糖膏剂Softw。英语。(ICSE)，美国新泽西州皮斯卡塔
版权声明：本文标题：再也不用举手之劳了？用ChatGPT评估代码生成的质量[期刊论文翻译] 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dongtai/1726698437a1081336.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论