clippy pass
Opened this issue · 12 comments
该issue的创生宣告了一次战争的尾声.
我想我会拒绝clippy的4格缩进意见, 但之后仍需启用clippy检查并重构部分语句.
我承认我的缩进问题, 我之后会认真参考rustfmt和clippy的建议. 另外, 给出建议时希望不要像异月一样开口就骂人, 而是把建议的原因简单写明, 我会认真参考这些建议.
所以其实免责应该放在这里。只不过我需要先确认能不能展开谈谈这个问题。
以一个非 ruster 纯吃瓜的视角， #10 所提到的 N+1 个 warning 实际上在一定程度上能反映出来这个程序“能跑，但有些地方一定是存在一点问题的”。
大项目可能会因为各种依赖的冲突而不得不出现一些 warning，当然了，他们也会有很多 issue 来尝试修正此类问题。
我的视角来看，对面的开发者是 ruster，并且他看到你的项目来到这里，本质上最开始是抱着学习心态的。但是他发现你的代码没有过 lint，包括 clippy 和 cargo-check，有些地方的处理还有些奇怪（反正从我的视角来看用 panic 来处理异常就挺奇怪的，还有滥用 static ，写其他语言的时候反正我是不敢滥用 static，容易出事），肯定是有些窝火的。
Github 不止于代码。这实际上就是围绕代码的一个社区。只是借助这个平台宣传自己开发的项目的话，完全可以像是 Fake Location 项目那样，只放一个 README 指明下载地点。然后再闭门造车。既然选择了开源，肯定会有人愿意修改并贡献代码的。
那么你现在把代码开放出来，实际上是允许大家对你的代码做出“或好或坏”的评价的。对吧。
实际上你俩魔法对轰了。对面语气也不好，你也没好到哪去。而且就代码的质量而言，考虑到你一开始确实没有过审查，你的劣势更大一点。况且还是你关掉了人家的 pr #11 。
建议去学学设计模式
没什么战争不战争的。如果就这点建议的接受与否就叫做战争，那每天在 github 上要发生多少战争。
双方都有一些小问题，可以改改哦。
其他的，请避免使用Best，“最”等字样。
另外，Warn 就相当于误差，可以减小，但是无法避免。若误差过大，可能会影响性能、使用体验等方面的问题
比如：一个async的function，不去等待就跟同步的 void function 差不多。
亦或者你使用了一些淘汰掉的方法/类/等，可能因为这些类有漏洞 \ 性能问题被淘汰
会提出 Warn。当然这个 Warn 是 最好避免，虽然能正常使用(漏洞触发除外)
亦或者，不按照标准写也能正常使用，但一般都会 Warn 提醒你有存在的风险
另外，缩进有利于其他网民一起改进本项目（当然不太可能了），增加代码可读性(要不试试读读不缩进的JSON文件？)。毕竟您都愿意开源了，不是吗？
严格一点，在H5开发中有个ESLint，您会选择关闭，还是按照标准来写呢？
Preview:
{"version":{"protocol":340,"name":"Hello world"},"description":{"text":"{\"attribute\":null,\"flag\":false}"}}
免责声明：我不使用指针，所以我对性能没什么追求，因为做桌面端应用程序开发。
另外，缩进有利于其他网民一起改进本项目（当然不太可能了），增加代码可读性(要不试试读读不缩进的JSON文件？)。毕竟您都愿意开源了，不是吗？ 严格一点，在H5开发中有个ESLint，您会选择关闭，还是按照标准来写呢？
我认同你对缩进的观点. 我习惯于2格缩进, 因此无法立刻接受4格缩进的建议. 我未来将会改正
“最精致的编程语言”有过誉之嫌，评价，不如py。但能写出来就蛮好的。
严格一点，在H5开发中有个ESLint，您会选择关闭，还是按照标准来写呢？
反驳一句,我会选择关闭. eslint 无意义的warning多的满天飞.大部分都是 少个空格 之类的.
- 要么有个工具能自动format到 可读性还行. (试过 typescript 和 tsx 真没有还行的.一旦某一行很长,就各种缩进各种换行,然后可读性一塌胡涂)
- 要么就不要让我浪费时间去手动优化format.我只想知道所有和逻辑正确性相关的 warning.
我想我会拒绝clippy的4格缩进意见
如果自动format效果不行, 我要是全用2格锁进,我也会拒绝 4格缩进意见. 这类无关正确性的warning,纯粹浪费时间.
pr #11 稍微看了下,里面全是 2格锁进,变4格锁进的改动. 改动行数过多(看上去几乎整个项目每行都改了), 很容易和其他pr冲突.
并且这个pr的描述信息很少.用 clippy 有啥好处?没讲. 为啥别人有动力去去和你的pr?
pr #11 稍微看了下,里面全是 2格锁进,变4格锁进的改动. 改动行数过多(看上去几乎整个项目每行都改了), 很容易和其他pr冲突. 并且这个pr的描述信息很少.用 clippy 有啥好处?没讲. 为啥别人有动力去去和你的pr?
Twhice's pr is just a sample about how to improve the quality of this shitting code. Although she just gave very few of information, Bylx666 has ignored it at all. And it is not the problem of formatting, the major problem is about the wild pointer and static variable usage. Some of this problems are corresponded with the code structure, but the code is unreadable which she had mentioned in #12. This made it impossible to improve the code.
支持仓库作者，另 rustfmt 的缩进格式是可以修改的
https://github.com/rust-lang/rustfmt/blob/master/Configurations.md#tab_spaces
我个人觉得 2 空格缩进很好…4 空格太容易超 120 了。但我感觉我的问题是我经常写 Java，它和 rust 类似都有类型表达式太长的问题。
使用什么缩进？我的建议是：
- 项目必须有统一的标准并且不要轻易改变
- 如果是新项目并且你能决定怎么缩进，遵守该语言或者该领域大多数人的标准
- 如果是新项目并且你不能决定怎么缩进或者是老项目，遵守项目的标准
年轻人，一定要听从自己内心的想法，这个仓库里你就是主宰！年轻人不狂还叫年轻人吗？让哪些动不动就给你提建议的人去食屎才是你应该做的啊！！！
lol
... firascript qwq