AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.
On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:
The last one is fairly new, but it looks extremely promising and it may work better for your project.
Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.
A useful IDE will not solve your problems! But it will make them slightly easier to manage.
I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.
As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.
As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.
发布评论
评论（2）
AutoIt 开发人员希望确保使用 AutoIt 编写的作为核心库一部分的任何函数（简称：UDF）都遵循特定的代码风格。您可以在这里找到该标准：http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm 社区中的许多程序员都在此标准中编写所有 AutoIt 代码。
关于IDE的话题。 SciTE 是一个经过时间考验的代码编辑器，但作为 IDE，它的性能已经足够了。还有另外两个由社区开发和维护的 IDE：
图形调试器（F10 下一步功能）http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/
ISN AutoIt 工作室 http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/< /a>
最后一个相当新，但它看起来非常有前途，并且可能更适合您的项目。
最后，我有一个警告。你说“OOP 原则很难应用”，但即使作为一个 OO 程序员，你在学习 OOP 之前也应该对如何编写非 OO 代码有一个strong核心思想。大多数面向对象语言的核心都是命令式的，因此您应该已经是一名优秀的命令式编码员了。 AutoIt 也是势在必行的。
一个有用的 IDE 并不能解决你的问题！但这将使它们稍微更容易管理。
我不知道您从哪里听说 AutoIt 仅对于 500 行以下的脚本表现良好，但每次您 #include 一个默认库时，您都会添加大约 10000 行代码。如果您可以编写正确的代码，您将构建自己的库，而不会增加其余代码的复杂性。
AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.
On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:
A graphical debugger (F10 step next functionality) http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/
ISN AutoIt studio http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/
The last one is fairly new, but it looks extremely promising and it may work better for your project.
Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.
A useful IDE will not solve your problems! But it will make them slightly easier to manage.
I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.
由于 AutoIt 不具备（正如您所提到的）面向对象语言的启用特征，我认为这里的部分答案是看看 AutoIt 有什么以及什么范式最适合它。我很清楚 AutoIt 是一种使用过程编程方法来完成的语言。对我来说，以这种思维方式回到这些方法实际上有点有趣。我的大型程序最终强调正确定义计算模块，即传递到模块（并返回）的内容。如果您严重错过了面向对象的好处，我认为接下来要关注的事情是范围界定——尽量保持范围尽可能严格。
最后一点，我认为使用过程编程技术通常最终会在功能启动并运行后创建一个单独的重构任务。
一个起点......但这是几十年来的主导范例
As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.
As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.
A place to start...but this was the dominant paradigm for decades