每个 Flutter 开发人员都应该知道的一些原则
前言
"仅仅让代码工作是不够的。有效的代码常常被严重破坏。仅仅满足于工作代码的程序员的行为是不专业的。他们可能担心没有时间改进代码的结构和设计，但我不同意。对于开发项目来说，没有什么比糟糕的代码更具有深远和长期的负面影响了。”- Robert C. Martin，Clean Code: A Handbook of Agile Software Craft-清洁代码: 敏捷软件工艺手册
正文
命名和函数参数
(错误使用)
返回值的方法不应该包含那么多参数。它应该采用 0(最佳) ，1 或 2 个参数。在这里的示例中，buildListTile 在命名和参数数量方面都很荒谬。如果我们给它一个合理的名称，并使用 ExtratWidget 而不是 ExtratMethod 创建一个 StatelessWidget，不是更好吗？耶！
提醒: 给这个方法起的名字非常重要。当命名一个方法时，“我应该如何命名它?”如果你这么想，很可能那个方法做了很多工作，而不是一项工作，这些就是我们污染了这个代码的第一个信号。
不要直接编写服务，而是使用抽象类。
(错误使用)
(正确使用)
提醒: 在项目代码中使用 TODO 是没有借口的。
如果有足够的代码可以用鼠标滚动，那么代码就不干净。
如果您正在创建的文件是 200 行或更多行，那么您已经做错了一些事情。你应该做更多的归档工作，写更多的函数。 例如，我在一些代码中看到的文件中有 2-3 个 TextFormField。两者非常相似。相反，您可以创建一个名为 CustomTextFormField 的结构，并在应用程序中的任何地方使用它。它在当前文件中占用了大约 10 行代码。但是在每个页面上重新创建 TextFormField 并不是正确的用法，因为它占用了很多行。时间和可读性是宝贵的。
响应式设计和颜色分配
(错误使用)
我们有义务设计与每个设备兼容的产品。就响应性而言，即使是一个非常简单的 widget 也不应该被忽视。即使在制作一个非常简单的应用程序时，也要习惯于响应式设计。小事带来大事。 我们需要创建一个名为 AppConstants 的类，并从那里调用颜色分配。我们应该把颜色定义为静态常量。这样它们就不会被反复编译。
Note: I am using the sizer package for responsive design.
提醒: 当命名颜色时，kPrimaryColor，kButtonColor 等等命名都是无意义的。我们必须写出颜色的名称。
不要低估 extension 、基函数、 Typedef 的威力。
你可以在我的个人资料里找到一篇更全面的文章。
别忘了使用 enum
一个例子枚举和 extension 协作如上所示。这些将如何帮助我们? 请进;
想象一下在服务函数中输入网址，那会很可怕。
其他建议
在 try catch 结构中，如果不需要，可以使用 catch() 而不是 catch(e)。
在 .then(value)函数中，如果不需要，可以使用. then()。
分离 UI 和业务层。例如，不要在 UI 代码所在的地方编写提取 api 函数。
在将服务集成到接口之前，总是要编写测试文件。观察那里的服务功能的行为。我以前写过一篇关于这个主题的文章。你可以回顾一下。
好好看看《Postman》的 API 吧。如果可能的话，手动创建模型文件并从 json_Series 化库获得帮助。模型中的变量是 int id，而不是 int？我定义为。为任何场景做好准备，即使您确信变量不为空。
文件夹、文件、类和函数的名称应该非常容易理解。罗伯特 - C - 马丁(Robert C. Martin)在这个问题上夸大了一点: “你应该像给第一个 child 命名一样小心地给一个变量命名。”
不能在项目增长时使用 Navigator.push() 等进行路由。这样你的页面就会重叠，你就无法控制了。相反，可以使用库手动创建路由结构。通过这种方式，您可以控制项目页，并且可以根据项目页的父页分支项目页。(AutoRoute，GoRoute 等)
“正确使用注释是为了弥补我们在代码中表达自己的失败。请注意，我使用了“失败”这个词。我是认真的。评论总是失败的。”
结束语
如果本文对你有帮助，请转发让更多的朋友阅读。
也许这个操作只要你 3 秒钟，对我来说是一个激励，感谢。
祝你有一个美好的一天~
© 猫哥
微信 ducafecat
https://wiki.ducafecat.tech
https://ducafecat.com