新手判断项目该不该用函数的唯一标准是看代码是否出现了重复和逻辑混乱，而不是看代码行数或项目大小。函数不是为了炫技，是你自己写代码时的"搬运工"和"整理师"，当同一段逻辑在你的项目里出现了两遍以上，或者一个操作步骤复杂到让你看着就头大,这个项目就明确需要函数介入了。
新手怎么判断代码要不要拆函数：三个硬指标
很多自学编程的朋友都有这样的困惑：自己写的小脚本一共就几十行，拆成函数反而觉得绕来绕去，不知道是在帮自己还是害自己，判断逻辑其实很简单，不需要懂什么高深的设计模式,就看下面三个指标。
同一个动作你重复做了两次以上
这是最直观的信号，你在项目里写了一段代码，作用是"把用户输入的手机号中间四位打码"，结果发现这个操作在注册页用一次、在个人信息页用一次、在后台列表里还要用一次，复制粘贴这段代码三次之后，你已经能背下来了,这绝对是拆函数的最佳时机。
具体操作路径是：
- 把第一次写的这段逻辑原封不动剪切出来
- 给它起个清晰的名字，比如
maskPhoneNumber或手机号打码 - 用这个函数名替换掉原来三次调用的位置
- 改其中任何一次的逻辑，其他两处自动生效
这个行为本身就是一个判断标准。如果你发现自己正在用Ctrl+C和Ctrl+V复制代码，且粘贴次数达到两次，立即停止，先把这段逻辑变成函数。
一个代码块超过15行且完成多个逻辑步骤
长度不是绝对的判断标准，但一个代码块超过15行且内部有多个逻辑步骤，先判断是否为空，再拆分字符串，再循环遍历，再拼接新格式，再返回结果"，这种体量已经不适合平铺在主线代码里了，你可以尝试用中文描述这段代码在干什么，如果能归纳成一个动词短语，格式化日期"或"计算购物车总额",就足以证明它具备函数的资格。
要留意的是，不要把函数写得过长，业内专家指出，一个函数超过30行时，阅读者就需要不停滚动页面才能看清全貌，大脑的负担会明显增加，因此拆出函数后如果它本身依然超过30行,就要检查内部是否还能继续拆分。
你的主程序开始需要大量注释才能看懂
代码一多，注释也随之泛滥，如果你发现自己的主程序里到处都是"下面这一步是处理价格的小数点""这里把列表倒过来"，这说明主程序的叙事线索已经被细节淹没了，函数的价值在于：主程序只保留"调用谁、传什么参、拿什么结果"这种高层叙事，至于具体怎么算、怎么倒序,全部丢给函数去处理。
一个健康的脚本应该是：主程序像一份菜单列表，每行对应一个函数调用，阅读者顺着菜单就能猜出程序在做什么，到了这层理解，你就不再需要问"这个项目该不该用函数"了，因为
函数已经是代码最自然的表达方式。
函数封装最佳实践：不同项目场景下的判断底线
在实际开发中，项目类型差异很大，函数的使用底线也不同，这里拆开来讲一讲,方便新手对照自己的场景。
一次性运行的爬虫脚本或数据清洗脚本
这类脚本的标准是"跑完即弃"，如果你只清理一次数据，后续不再复用，函数不必强行拆得细碎，但即便如此，一个超过50行的脚本，依然建议至少拆出一个主函数和两三个辅助函数，这出于另一个考量：你在命令行终端里反复调试时，如果所有逻辑都堆在全局,那么任何一点修改都可能影响其他不相干的操作。
实操中比较稳妥的做法是：脚本本身按"读取数据→处理数据→输出结果"三个步骤各拆一个函数，主流程用几行代码把这几个函数串起来，这种做法会让调试时定位错误的位置变得很快，在终端里用python -m pdb或traceback查看报错时,函数名能直接告诉你问题出在哪个环节。
页面展示类项目如小程序、网页前端
这类项目涉及交互事件和状态变更，函数的使用判断会稍有不同，一般建议按"一个事件对应一个函数"的规则处理，点击了提交按钮"对应一个handleSubmit函数，"用户修改了密码输入框"对应一个handlePasswordChange函数。
判断这类项目该不该再往下拆，看的是事件函数内部的复杂度。事件函数内部如果同时出现了三件以上的事情，比如既要读取表单值、又要做格式校验、还要调接口、还要刷新页面列表，那么就应该把"格式校验"和"调用接口"分别独立成函数，这种拆分不是为了复用，单纯是为了让单次事件的处理逻辑变得可读、可调试。
算法练习或力扣刷题环境
这类环境通常单文件、无外部依赖、代码总量在几十行以内，很多算法题本身就是让你实现一个函数，内部逻辑复杂且高度内聚，这种情况下，不需要强行把题解的局部循环拆成额外函数，除非你发现同一个子步骤在同一道题里被重复计算了两次以上（比如重复遍历同一个数组），拆函数在算法题里更多是优化代码可读性,而不是工程复用。
判断算法题里的函数体是否过长，可以看代码中的循环嵌套深度。超过三层嵌套的循环结构是强烈建议拆出的，因为三层以上嵌套的缩进会让多数人读起来感到困难，你可以把最内层循环体提取成函数，传入必要的参数，这样主循环就只剩两层,逻辑清晰不少。
新手学函数常见误区：哪些情况不该硬拆
给项目引入函数并不总是正确答案，对于正要学习的新手而言，识别"不必用函数"的情况,同样属于基本功。
整个项目只有一段逻辑，且不会扩展
如果你写了一个脚本，功能只有"把华氏温度转成摄氏温度"这么一件事，整段代码一共五行，那么直接写出来就好，完全没有封装必要，额外的函数定义、参数传递、返回值接收，对这段代码的阅读来说构成了多余的心智负担，行业共识认为，当代码的逻辑分支少于三个且总共不超过十行时，直接平铺优于函数封装。
判断一个项目未来是否会扩展，可以问自己一个问题：这个东西三个月后我还会改吗？如果答案是"绝对不会"，那不拆也罢,不要被洁癖绑架。
一个函数被塞进了七八个参数
这是另一个极端，有些新手意识到要拆函数，但拆法不对，比如做一个"创建用户"的函数，把用户名、密码、手机号、邮箱、年龄、性别、地址、头像路径全部作为参数传给函数，这其实不是函数化，这是把代码里的临时变量搬了个家,没有任何实质改进。
判断参数是否过多的标准是：当你调用这个函数时，你记不全该传哪几个参数，需要反复切回去看函数定义，这就说明参数已经超过大脑的实时记忆窗口了，准确值大约是四到五个参数以内，这种情况下应该考虑把相关参数打包成一个数据对象，再作为单个参数传入，或者在函数内部自行获取数据,而不是全部依赖外部传入。
频繁读写的全局变量变成函数的隐形传参
新手比较容易在"全局变量"上栽跟头，一种常见写法是：整个项目里定义了多个全局变量，函数内部直接读写这些全局变量，而不是通过参数和返回值传递数据，这样的函数看似拆分了，实则和主程序完全耦合在一起改一个字段，所有相关函数都要跟着调整，这种做法做得越多，项目越难维护,连命名规范都变得很难执行。
判断自己是否掉进这个陷阱：如果你在每个函数开头都要专门写一行global xxx来声明外部变量，那么强烈建议你在封装函数之前，先用参数传递的方式重构数据流，函数应该是高度自治的：传入明确参数、返回明确结果,最好做到不碰任何外部状态。
如何用函数判断你的项目规模是否失控
这是一个利用函数反向审计代码的好习惯，当你在一个项目里改代码改到一半，不确定自己是不是把项目写散了,可以做一个简单的检查：
- 数一下项目中现有的函数数量、每个函数的行数和参数个数
- 若出现一个函数超过50行的情况，要特别警惕
- 若出现同一函数内部出现多个完全无关的业务步骤，则是明显需要拆分的信号
多数情况下，一个正常规模的中小型项目如果要兼顾可读性，函数数量会稳定在20到60之间，各函数长度相差不大，如果函数数量过多，比如一个小脚本拆了二十个函数，大概率是过度设计了，说明项目核心逻辑实在简单,不需要那么多中转到不了国王的中间人。
判断视角：反过来看，不用函数会付出什么代价
有人可能会问："我看这项目只用一次，不用函数真的会造成严重后果吗？"从短期来看，确实不一定，但从稍长一点的视角看，代价是很实在的：当你第二天接着写时，要花二十分钟回忆昨天的代码逻辑；当你遇到一个bug时，要在密密麻麻的代码里手工定位，而不是一眼锁定函数；当你想对某个功能做微调时,可能会不小心改坏另一个无关的功能。
很多自学编程的人放弃项目，不是因为项目太难写不出来，而是因为写到一半自己都看不懂自己写的代码了。函数不是给电脑看的，是给三周后的你自己看的。如果你预感到三天后的自己会对着现在的代码皱眉,那么现在的你就有义务拆出一个清晰的函数。
函数相关常见疑问
函数用的次数不多，但代码确实很长怎么办
参考上面的长度指标，一次使用但超过15行的逻辑，依然建议封装成函数，这更多是出于可读性考虑，不是为了复用，函数有一个很实用的附加作用：折叠。大多数现代编辑器支持折叠函数体，封装之后，你就能把这段长逻辑折叠成一行，让主程序看起来干净很多，不是只有"用两次以上"才能拆,长得过于拥挤的代码块同样值得拆。
函数是要写在主代码前面还是后面
两种方式都能运行，但考虑到代码阅读顺序，推荐把函数定义集中在主程序之前，或者放在单独的模块文件中，如果你使用Python这类脚本语言，函数定义必须出现在函数被调用之前（模块加载时先完成定义），实操中常见的方式是：顶部导入所需库，接着罗列所有函数定义，最下面单独放着主程序执行入口，如果项目稍大，建议直接把函数封装到独立的.py文件中使用import导入,逻辑会被梳理得更清晰。
函数和类该选哪个
先从函数入手，类是对"数据加函数"的更高一层封装，在函数没有熟练之前直接接触类，容易混淆职责边界，判断项目需要类的信号是：你发现有两个函数反复操作同一批数据，比如一个项目里反复读同一个文件路径和配置字典，而且需要保持状态一致，这时把数据对象和操作它的动作绑定成一个类才合适，在那之前，单纯依靠函数已经够用，所有采用函数式写法就能表达清楚的逻辑,不碰面向对象是正确的习惯。
判断的最终标准永远不是"会不会用"，而是"用了之后，这个项目是不是更好懂、更好改了"，一次两次拆得不完美一点也不可怕，可怕的是用"项目太小不用管"的借口一直逃避，动手拆过几次函数，再回头看平铺的代码,你会自然得到属于自己的那个判断标准。