代码拉取完成，页面将自动刷新
同步操作将从 vicwjb/AutoLispBaseFunctionLibrary 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
# AutoLispBaseFunctionLibrary
#项目简介 这是一个关于autocad 的二次开发语言autolisp/vlisp的通用的基础函数库。 ##发起原因 在学习和写autolisp的过程中，学习了很多前辈的代码，好吧我承认是抄。
这些代码零散，需要人整理，虽然网上也有这种整理好的，但是由于发布体制的原因，可维护性及可靠性完全依靠发布者，相当的脆弱。
所以发起这个项目，只是想大家都参与进来，共同建立一个大家能使用，大家能参与的项目，这个项目不依赖任何人的强制想法。 ##代码来源 本项目初始代码来至于我个人整理的一些代码和自己写的代码。
感谢lee mac，高飞鸟，gu_xl，飞诗，熊掌，还有其他的我也记不住名字的人。
能确定代码来源的尽量都加上，没能加上的，如果你反对你的代码加入这个项目，请联系我，我会删除。 ##项目文件结构
##声明 本项目在有意向的时候，就有人说我是钓鱼，我只想说，滚你妈。
如果为了钓鱼，我不会用了一个月的业余时间来把代码都整理出来，基本上每个都测试过能正常工作。
如果为了钓鱼，我不会把每个函数都写上注释，都生成文档。
如果为了钓鱼，我只想说，愿者上钩，我先上钩了。
最后，请不要以恶意来揣测别人，除了证明你的浅薄，我想不出你还有何价值。
本编码规范参考google common lisp 风格指南结合AutoLisp的特点编写。
每一个开发者所写的代码必须让别的开发者容易阅读、理解及改动 ──── 即便最初的开发者已经不在了。（这是 “hit by a truck” 理论。）
当抉择如何写出一段给定的代码时，依此优先序追求下列性质：
这些准则大部分都是直观的。
客户的易用性代表系统满足了客户的需求；如：需要处理客户的交易量，正常运作时的需求等等。
针对 Lisp 效率这一点，若是有两个同样复杂的选择，选运行较好的那个。（通常是构造比较少的那个，也就是从堆上配置了较少空间。）
给定两个选择，其中一个比另一个复杂，选择简单的那个，并分析出另一个有更好效能时，才重新审视当初的决定。
然而，避免过早优化。别为了给不常用到的代码提升速度而使复杂度上升。因为长期来说，鲜少运行的代码快不快不是那么重要。
必须在注释里使用正确的拼写，而最重要要拼对的是函数的形参。
当数个正确拼写同时存在时（包括美式及英式英语），而开发者之间尚未有共识存在时，你应该选择较短的拼写。
必须只使用常见与领域相关的缩写，缩写保持一致。可以把受限作用域里的词法变量缩短，来避免符号名称过长。
如果你不确定的话，查字典吧，或是 Google 下来检查拼写。或问问当地的专家。
应该要格式化你的源代码，使单行不超过 100 个字符。
有某些行长限制总比没有好。古老的文字终端机使用 80 栏，但现在允许 100 栏似乎比较好，因为好的风格鼓励你使用具有描述性的变量以及函数名称。
像配置好的 vlide/其他编辑器 那样缩排你的代码。 （建议使用飞诗Lisp编辑器）
项目里维护一个一致的缩排风格。
审慎的缩排会使代码更容易理解。
垂直空间：顶层级别的形式，一个空行。
应该在顶层级别的形式留一个空行，比如函数定义。在特殊情况下，空行可以省略，简单的、密切相关的、同种类的定义形式，比如一组相关的类型声明，或是常量定义。
空行可以把复杂的函数切分成多个部分。一般来说，你应该要把大函数切成几个小函数，而不是添加垂直空间，让它读起来比较好读。如果你不能够切成小函数，你应该要使用 ;; 注释，说明每个函数的部分各是干嘛的。
水平空间：括弧之间不要有空格、tab。
绝对不要在括号或符号的前面或后面加上额外的空白。
;; 非常差劲
(defun StrUnParse ( Lst Delimiter / return )
( setq return "" )
( foreach str Lst
( setq return ( strcat return Delimiter str ))
)
( substr return 2 )
)
;; 较佳
(defun StrUnParse (Lst Delimiter / return)
(setq return "")
(foreach str Lst
(setq return (strcat return Delimiter str))
)
(substr return 2)
)
形式之间应该只用一个空格。 你不应该在多行连续的中间，使用空格来垂直排列形式。一个例外是当代码不垂直对齐，就看不出你要强调的重要性时。
;; 差劲
(setq low 1
high 2
sum (+ (* low low) (* high high)))
...)
;; 较佳
(setq low 1
high 2
sum (+ (* low low) (* high high)))
...)
你必须排列嵌套形式，如果他们超过一行的话。
;; 差劲
(defun munge (a b c)
(* (+ a b)
c))
;; 较佳
(defun munge (a b c)
(* (+ a b)
c))
所有函数都应该要使用文档字串，来解释如何使用你的代码。
除非某段代码完全一目了然，不然就上一个文档字串（别名 docstring）。
文档字串生来就是给使用代码的程序员读的。他们可以从函数、类型、类别、变量以及宏取出， 并通过编程工具，如 IDE 来显示。因此，文档字串是给你的 API撰写文档的完美地点。应该描述如何使用代码（包括需要避开的陷阱），而不是代码是如何工作的（以及之后所需的工作），这两个是你该放在注释的东西。
当定义一个顶层及别的函数、类型、类别、变量以及宏时，提供一个文档字串。一般则是在程序语言允许加入文档的地方，添加文档字串。
关于函数，docstring 应该要描述函数的合约： 这个函数干什么， 这个函数的参数表示什么， 这个函数所返回的值， 这个函数可捕捉的状况。 应该在适当的抽象层级上来表达，解释意图，而不仅是解释语法。在文档字串里，将 Lisp 符号的名字转为大写，比如函数参数。
以上应该是用于文档工具生成API文档的文档字串。鉴于AutoLisp貌似没有文档工具支持，因此可以使用分号注释及块注释。
你必须使用正确数量的分号来写注释。
注释是给未来维护代码的人的说明。即便你是唯一能够看与接触到代码的人，即便你长生不老或是永远不离职，或是离职之后根本不管的人（并在这种万一的情况下使你的代码自行毁灭），你可能会发现给代码写注释是有帮助的。当然啦，在几个礼拜、月、年之后，回头看看代码时，你会发现当初写这个代码的人，完全与你不是同一个人，则你会感激当初自己有留下注释。
你必须给任何复杂的代码留注释，这样一来下个开发者才可以了解情况。（又来了，“hit by a truck” 理论。）
注释也可以作为指引阅读代码的人的一种方式，这样他们才知道这里有什么。
在分号与注解文字之间，应该留一个空格。
使用小写。
所有的符号使用小写。一致地使用小写，除了可读性更高之外，也让查找符号名变得更容易。
注意AutoLisp不区分大小写，而对一个符号调用 vl-symbol-name 时，会返回大写。由于这个转换大小写的特色，当你试着要分辨符号的大小写时，最终只会让你陷入困惑。
在符号的单词之间放连字符。如果你不能很简单的说出标识符的名字，那符号大概命名的很差劲。
连字符必须用 "-"，不要用 "/" 、":"或是 "."。除非你有一个无懈可击的理由，以及你的提议取得了来自其他黑客的许可。
;; 差劲
(setq *default-username* "Ann")
(setq *max-widget-cnt* 200)
;; 较佳
(setq *default-user-name* "Ann")
(setq *maximum-widget-count* 200)
除非变量的作用域非常小，不要使用过短的名字，像是：i 以及 zq。
将变量用目的命名，而不是变量的内容。
应该根据变量所意涵的概念命名，而不是根据概念在机器底层是怎么表示的来命名。
因此，你应该避免嵌入数据结构或结合类型名称，比如将 list 嵌入变量名，除非你正在写一个通用的演算法，适用于任何的列表等等。在这个情况下，变量名有 list是完全没问题的。
举例来说，如果一个变量的值，总是一个 row（或是NIL），叫它 row 或 first-row 是很好的，或者是其他相似的名字。严格来说，因为你将细节抽象起来了，剩下的亮点是，它是一个 row。
保持一致。如果变量在一个函数里命名成 row，且它的值被传给第二个函数，则将其称为 row 而不是 value。（这是一个实际情况）
全局变量名应由星号开始，并以星号结束（在这个上下文里，星号又称为耳套「earmuffs」）。
(setq *maximum-search-depth* 100)
判断式函数与变量的名字以 "P" 结尾。
你应该将返回布尔值的函数与变量的 结尾以 "P" 或 "-P" 命名， 来表示他们是判断式。 一般来说，你应该使用， 函数名是一个单词时，使用 "P"； 超过一个单词时，使用 "-P"。
为了要统一，你应该遵循上面的惯例，而不是下面其中一个替代方案。
###前缀 因为AutoLisp的糟糕的名称空间管理，所以尽量使用一个特殊的前缀来避免变量冲突。 建议前缀：
函数名应该包括处理对象的类型、处理目的。 示例：
(defun BF-list-additem (lst index item)
...)
不是必要的情况下，避免使用副作用。
Lisp 的最佳用法是"以函数式风格为主"。
避免改动局部变量，重新绑定试试。
你应该偏好迭代胜于递归。 因为递归很容易造成栈溢出。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手