youngsoft
注意命名规范
性能到底怎么样，没有亲自测试过也不好评论。
但是命名很不规范让人没有使用的想法。比如说： ① S.widthSize.equalTo(@100); 暂且不说大写的S，width已经表达了宽度的含义了，为什么还要画蛇添足的在width后面加上Size？你做iOS开发的难道不清楚Size是个结构体吗？ ② 再比如说A.rightPos.equalTo(@0.3); 实在不知道你这个Pos想表达什么含义，右间距还是什么别的？Masonry用mas_right来表示，CSS用margin和padding来表示，所以我实在不能理解是什么意思。 ③ C.myWidth = 50; 你这里想表达C视图的宽度，那直接c.width = 50;不就行了吗？为什么非要加上my来表达宽度的含义 ④ S.coordinateSetting.origin = CGPointMake(0.5, 0.2); coordinateSetting本身就可以用coordinate来表达含义了 ......
命名规范的问题实在太多了，开发者设置一个视图的size根本就不会想到输入“my...”然后让IDE来提醒输入什么，而且视图的代码写多了，像这种满屏的不规范命令看起来也让人不舒服。
有些命名可能会跟系统的产生冲突，可以考虑像Masonry那样添加一个mas_的前缀来解决
建议能改进一下
非常感谢你的建议，其实这些是有历史原因的：最开始开源时功能很简单而且命名更加混乱，后来其实是有一波改进的。在Swift版本的TangramKit中对命名才进行了更加合理的规范处理，您可以看看Swift版本的命名就知道了。
其实对于文中提到的比如width,left这些属性是不能直接作为UIView的扩展分类来设置的，因为这个名字太大众化，有很大几率会跟其他库重名。解决问题的最佳解决方案就是使用固定前缀或者再建立一个命名空间。
最后之所以OC版本这样的原因是因为目前库还是有很多用户的，一旦名字修改就势必会需要引起接入方的一大波适配操作。所以只能通过其他一些方式来慢慢改进。目前我有在思考是否需要对OC版本的各种属性进行一次大的重构处理。
我一开始也是感觉到命名的别扭之处，但是一直往下看，才感觉出这个框架厉害之处。命名只是代码的一部分，跟牛叉的功能比起来是显得不那么重要了，但是往往厉害的框架都是有着优雅的命名规范的。
作者考虑到使用者适配问题也是可以理解的哈，但是命名问题是应该尽早规范起来的，因为越往后可能历史包袱越重。并且不能为了考虑老用户感受，不考虑新用户嘛。
可以参考Swfit2到Swift3的升级，简直地动山摇的变化，但是更新之后确实又让人信服，那些多余的，表达模糊的概念都是应该优化的。同时也意味着苹果对Swift推崇的决心和Swift的优秀之处。
当然我也尊重作者的决定，团队之力和个人之力还是没法比的，但还是希望作者大大能够做命名优化哈。
随着这个库使用人数的增加，影响力的扩大，命名规范化是必然的，任何一个优秀的开源项目命名应该都不会这么混乱，虽然是历史包袱的原因，但是还是应该像楼上说的那样朝着更优秀的方向前进
