lua垃圾代码生成器最佳垃圾代码

转载

mob6454cc69d373 2024-07-02 10:00:38

文章标签 lua垃圾代码生成器程序员 GitHub 开源仓库 文章分类 游戏开发

好的代码可以像诗一样优雅，然而并非人人都能写的一手好代码！老实说，想写一手不被同事吐槽的代码确实不容易，

特别是有的小伙伴在工作中公司都没有明确的代码规范，或者仅仅只是一些口头约定，这样就更难养成一些良好的代码书写习惯了。

不过 IDEA 中有一个 Alibaba 代码规范插件，可以自己装着起一个约束提醒自己的作用。

lua垃圾代码生成器最佳垃圾代码_GitHub

最近小编在 GitHub 上看到一个开源项目，还挺有意思的，作者罗列出了什么样的代码是垃圾代码，仓库地址如下：

> > > h删ttp删s://删git删hub删.com删/trek删hleb/删stat删e-of-th删e-art-s删hitc删ode

以一种容易造成代码混淆的方式命名变量

命名越短，就需要越多的时间去思考代码逻辑等问题。

Good
inta =42;
Bad
intage =42;
变量/方法命名风格不统一
为风格不统一干杯。
Good
intwWidth =640;
intw_height =480;
Bad
intwindowWidth =640;
intwindowHeight =480;
不写注释
反正没人能读懂你的代码。
Good
intcdr =700;
Bad
注释应该包含一些“为什么”，而不是一些“是什么”。如果代码连是“什么”都表达不清楚，那代码也太烂了。
//700ms的数量是从UXA/B测试结果中得到的一个经验值。
//@查看:<详细解释700的一个链接>
intcallbackDebounceRate=700;
使用母语写注释
如果你的母语是英语，那么请忽略这条准则。
Good
// Закриваємо модальне віконечко при виникненні помилки.
toggleModal(false);
Bad
// 隐藏错误弹窗
toggleModal(false);
PS：如果英语书写能力不是很强的话，建议还是用母语吧。毕竟说清楚总比说不清楚要强。
声明变量的风格不统一
再次为风格不统一干杯。
Good
String[] i1 = {"沉","默","王","二"};
Stringi2 [] = {"沉","默","王","三"};
Bad
String[] wanger = {"沉","默","王","二"};
Stringwangsan [] = {"沉","默","王","三"};
尽可能把代码写成一行
Good
IntStream.range(1,5).boxed().map(i -> { System.out.print("Happy Birthday ");if(i ==3)return"dear NAME";elsereturn"to You"; }).forEach(System.out::println);
Bad
for(inti =1; i <5; i++) {
System.out.println("Happy Birthday "+ (i ==3?"dear NAME":"to you"));
}
对错误信息不管不顾
无论什么时候发现错误，都没有必要让其他人知道。
Good
try{
// 意料之外的情况。
} catch (error) {
  // tss... 🤫
}
Bad
try{
// 意料之外的情况。
} catch (error) {
  // and/or
  logError(error);
}
使用大量的全局变量
全球化的原则。
Good
intx =5;
void multi() {
x = x *2;
}
multi();// 现在 x 是 10
Bad
intx =5;
int multi(int num) {
returnnum *2;
}
x = multi(x);// 现在 x 是 10
声明根本不会使用的变量
万一以后用了呢？以备不时之需。
Good
int sum(int a, int b, int c) {
inttimeout =1300;
intresult = a + b;
returna + b;
}
Bad
int sum(int a, int b) {
returna + b;
}
如果条件允许的话，从不指定类型。
Good
//享受便捷的快乐
List list =newArrayList();
list.add("沉默王二");
list.add(18);
Bad
List nameList =newArrayList();
// 编译出错
nameList.add(18);
没鸟用的代码
看起来更严谨，其实很多余。
Good
Integermulti(Object num){
if(!(numinstanceofInteger)) {
returnnull;
}elseif(num !=null) {
return(Integer) num *2;
}
returnnull;
}
Bad
Integer multi(Object num) {
if(numinstanceofInteger) {
return(Integer) num *2;
}
returnnull;
}
大量的 if-else 嵌套
Good
void someMethod(int a, int b, int c) {
if(a >0) {
if(b >0) {
if(c >0) {
intresult = a / b / c;
}
}
}
}
Bad
void someMethod1(int a, int b, int c) {
if(a <0|| b <0|| c <0) {
return;
}
intresult = a / b / c;
}
参差不齐地缩进
参差不齐乃幸福本源。
Good
String[] wanger = {"沉",
"默","王","二"};
String[] wangsan = {"沉","默","王","三"};
Arrays.asList(wanger).stream().
forEach(System.out::println);
Arrays.asList(wangsan).
stream().
forEach(System.out::println);
Bad
String[] wanger = {"沉","默","王","二"};
String[] wangsan = {"沉","默","王","三"};
Arrays.asList(wanger)
.stream()
.forEach(System.out::println);
Arrays.asList(wangsan)
.stream()
.forEach(System.out::println);

代码行数多的方法的比少的好

不要把代码逻辑分成可读的部分。

一个类中的代码行数超过 10000 行。

一个方法中的代码行数超过 1000 行。

一个方法里既做减法处理又做加法处理，还做乘除的处理。

不要测试你的代码

代码测试是测试工程师的事，关我屁事。

避免代码风格统一

随心所欲地编写代码，特别是在一个团队中有多个开发人员的情况下，我崇尚“自由”。

不要写文档

从一开始就不要。

不要删除废弃掉的代码