变量后面加感叹号，加了个寂寞

Creator 3.x
#41

这是胡搅蛮缠吗？
那我是不是可以回，这么不喜欢搞，大家都去用php、js吧。
这里讨论的就是ts的语法，ts严格模式就是如此，难道是引擎要这么约束呢？还是我强迫这么用的呢？

1赞
#42

单纯吐槽一下严格模式而已 不要上纲上线

#43

编译阶段提示我的目的是什么？让我做类似 if(!obj) 的判断？
我要表达的是，大部分这种判断是没必要的，数据非法运行后自然会报错，这样就能及时解决掉非法数据产生的来源，bug才不会堆积。
反而加了非法判断，看似健壮了，其实产生非法数据的地方依然存在，只是该报错的时候没报错而已。
所以严格模式，以及加！来打补丁都是不成立的

#44

个人认为你可能弄混了编译检查和运行检查
第一种情况：
现在假设非严格模式下，这里为空是一个非法的，那么此时，是不是为空的时候运行报错。
好了，现在是严格模式，请问你加了感叹号，是不是依然报错。
所以，在这种情况下，加感叹号，并没有改变最终结果。而你说的额，该报错没有报错，我不知道是什么情况。
第二种情况:
这里可以为空
非严格模式下，是不是可能没注意到为空判断
那么严格模式下，编译器就会给你提示，这里肯能为空，那么你就可以加?解决
但是，有些地方，我们已经知道肯定不为空了，再加问号，是不是产生多余的代码和后续一系列非空判断，那么这个时候你是不是要告诉编译器，你这里是不为空的，让编译器跳过这个空检测，那么你加感叹号就可以了。
还是那句，很多人线上问题是空的问题，那么编译器能及时告诉你可能为空的地方，而!的作用就是，当你明知时可以让编译器跳过检查。

#45

其实不太好用，即便开了严格模式，函数返回值明确了可能是空，你的同事依然可以使用!.强制跳过检查。
得对于特别讲究的人才有用。

#46

你表达的很清楚，严格模式、!的作用都讲明白了。
我要表达的是一种新思路：
无论什么参数，一律视同可能为空。
是否需要做非法判断，取决于参数来源是否由自己掌控。
如果是由自己可控的，那么就不应该做非法判断，这样一旦出现非法数据才可以及时报错，以便及时排查非法数据来源。（如果允许为空，那当然要处理为空的情况）
如果数据不是自己可控的，比如是服务端传过来的，或者用户输入的，那必须要做非法判断。
————————————————————————————
基于这种思路，整个严格模式都是不需要的，加!这种给严格模式打补丁的语法自然也没必要了

#47

所以某些大神，喜欢用js。
但是，还有很多我这种小白，需要编译器告诉我可能的错误

#48

我也用ts，这不是ts和js的问题
就讨论严格模式和!语法的必要性
我倒很希望有人能说服我，但目前来看确实没什么必要

#49

举个例子
通过 name 获取子节点

let node = this.node.getChildByName(`test`)

这个结果毫无疑问的它有可能是空的，非严格模式下，这个结果可以直接拿来用，编译器不会要求开发者考虑空的情况，比如直接设置 node.active = false 是不会报错的，但是运行时会出错

严格模式下，编译器会要求开发者必须检查这个结果是否安全，好处是可以在开发阶段直接避免掉这种错误，比如在严格模式下同样的设置 node.active = false 这样写是不行的，必须要要判断一下 node 是否有值

if (node) {
    node.active = false
}

然后就是 ! 的作用了，如果说我确定通过 test 肯定能拿到节点，因为是我亲手拖上去的，那么就可以通过 ! 告诉编译器: 你不用提醒我了，我知道这里一定有值。

node!.active = false

严格模式的好处就是在开发阶段避免掉这种空结果带来的异常问题

2赞
#50

什么意思？加了!的意思是你能保证这个变量不为空，这时候报错了那不是你的问题么？这个叹号的名字叫“null包容运算符”（可以到mircosoft learn搜文档），它的意义就是让编译器参与检查可能造成空指针异常的地方，TS通过类型声明保证没有编译错误，通过这个运算符减少运行时错误发生的概率呗

#51

为什么要加if(node)的判断呢，node如果为空，就应该让他报错啊，这样你才能第一时间解决为什么是空的，如果这里业务场景是允许空的，就对if(node)后面做相应的逻辑处理
整个流程下来都不需要严格模式，更不需要！

#52

这…
你别告诉我，你没遇到过，node有则走，node为空则不走的正常逻辑需求
另外，我都说了，有很多是我这种小白，老是不知道这里可能为空，而严格模式下，编译器会告诉我
但是如果编译器要提示，他就不知道这里是不是存在一定不为空的情况下，这个时候你可以!告诉他
我觉得我再反复说一句话~

#53

我是用这个举个例子，你可以把这个 node 当做是从服务端获取到的数据，如果非严格模式下开发阶段忘记了做判断，在正式发布后如果服务端出问题了，这里的业务就出错了，但是如果是严格模式下，编译器会要求你必须判断，不判断的话编译不过会报错。

#54

你的这些回复，都是建立在你自己的逻辑之上。换句话说你觉得你可以靠自己的经验、逻辑把代码写健壮。TS、严格模式的意义就是让新手也能把代码写健壮。

学计算机的都学高数，记得微积分和牛顿-莱布尼茨公式的关系吧？一个事物要发展，必然是要越来越简单，能让越来越多人接触。

#55

其实按他的逻辑，trycatch也是不必要的
既然你认为有问题，就应该修改
既然你认为没有问题，就不应该加trycatch

2赞
#56

我是最追求极简的，问题是严格模式目前来看没有意义，反而增加多余的判断逻辑
普通模式把是否做非法判断交给使用者自己，如果连这种都要靠编译器来提醒，那说明对自己代码完全没有掌控力

#57

我的项目从来不会加try catch，一个道理，这样会掩盖真正报错的地方导致Bug堆积起来
自己写的代码，肯定要100%掌控，哪里不符合预期就及时发现改掉

#58

我已经非常委婉了，我其实想说程序员中能够完全处理null的，全世界加起来最多2个人，我不知道2个是谁，只是为了相对严谨

1赞
#59

关严格模式就好了 不要那么纠结 怎么舒服怎么来 我从来不开

#60

那没办法，你是真大神~