在仅供内部使用的代码中进行额外的检查是一个好习惯吗?
是否有必要检查代码中的所有参数和其他条件,如果我知道,我永远不会传递错误的参数,它应该可以正常工作(假设我已经在该代码之外进行了一些检查)。
示例:
此代码:
/**
* Applies function to all elements of array in specified
* context.
* If array is empty, returns null.
*/
MyNameSpace.foreach = function(arr, callback, context) {
if (!(arr instanceof Array)) {
throw new Error('first argument is not an array');
}
if (typeof callback !== 'function') {
throw new Error('callback is not a function');
}
if (typeof arr.length === 'undefined') {
throw new Error('Length undefined');
}
var con = typeof context === 'object' ? context : window;
var i = arr.length;
if ( i <= 0 ) {
return null;
}
for ( j = 0; j < i; j++ ) {
callback.call(con, j, arr[j]);
}
}
可以是:
MyNameSpace.foreach = function(arr, callback, context) {
var con = typeof context === 'object' ? context : window;
var i = arr.length;
if ( i <= 0 ) {
return null;
}
for ( j = 0; j < i; j++ ) {
callback.call(con, j, arr[j]);
}
}
Is there sence to check all arguments and other conditions in code, if I know, I never pass wrong argument and it should work fine ( say I already made some checks outside of that code ).
Example:
this code:
/**
* Applies function to all elements of array in specified
* context.
* If array is empty, returns null.
*/
MyNameSpace.foreach = function(arr, callback, context) {
if (!(arr instanceof Array)) {
throw new Error('first argument is not an array');
}
if (typeof callback !== 'function') {
throw new Error('callback is not a function');
}
if (typeof arr.length === 'undefined') {
throw new Error('Length undefined');
}
var con = typeof context === 'object' ? context : window;
var i = arr.length;
if ( i <= 0 ) {
return null;
}
for ( j = 0; j < i; j++ ) {
callback.call(con, j, arr[j]);
}
}
could be:
MyNameSpace.foreach = function(arr, callback, context) {
var con = typeof context === 'object' ? context : window;
var i = arr.length;
if ( i <= 0 ) {
return null;
}
for ( j = 0; j < i; j++ ) {
callback.call(con, j, arr[j]);
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这绝对是一个很好的做法。它可以提高应用程序的稳定性并帮助调试。缺点是它会使代码变得混乱(使其难以阅读),并且会影响性能(尽管对于大多数 JavaScript 应用程序来说,性能并不重要)。
你必须针对每种情况采取看法。这实际上取决于(1)参数不正确的可能性有多大以及(2)如果参数不正确将会造成多大的损害。
Absolutely it can be good practice. It can aid the stability of your app and help with debugging. Downsides are that it can clutter the code (making it harder to read) and that it can have an affect on performance (although for the majority of JavaScript apps performance won't be critical).
You have to take a view in each case. It really depends (1) how likely it is that the parameters will be incorrect and (2) how much damage it will do if they are.
虽然如果在生产中保持启用它可能会稍微减慢执行速度,但您可以在生产中或调试期间使用类型检查库:
...在您的情况下,您可以按如下方式使用:
通过这种方法,您可以分离出丑陋的类型检查代码,如果您只在测试期间需要它,甚至可以禁用它。您可以进一步添加用于参数或属性值检查的方法。
Although it may slow execution a little if you keep it enabled in production, you can use a type checking library, either in production or during debugging:
...which in your case you might use as follows:
With this approach you can separate out the ugly type checking code, and even disable it if you only need it during testing. You could further add methods for argument or property value checking.
软件中测试输入和输出的一般原则是:“输入灵活,输出严格”。您应该始终对您的输入进行额外的检查,以便您的代码在您的方法得到不期望的结果时不会中断。
The general principle in software when it comes to testing inputs and outputs is: "Be flexible on inputs, strict on outputs." You should always have additional checks on your inputs so that your code doesn't break if your method gets something it doesn't expect.
这绝对是一个很好的做法,因为任何使用您的类或函数的代码都可能在不知不觉中向您传递值,这可能会导致您的代码崩溃。
例如:一位程序员曾经不小心向我的代码发送了一个 NULL 指针,该代码必须对指针指向的对象进行深层复制。
但由于我在复制构造函数的初始化列表中克隆指向的实例,所以没有人能弄清楚程序崩溃的原因。
程序员说我应该检查 NULL 指针,但最终我们决定在他这边保留检查,因为我们需要保持通过初始化列表进行复制的效率,这样更快。
因此,您可以根据以下情况决定是否进行支票:
1. 使用复制构造函数初始化列表的效率。
2. 您对函数/类的输入参数和限制的记录情况如何。
3. 您的代码是否会因恶意输入而崩溃/产生安全问题
4. 您的软件需要什么样的异常处理。
It's definitely good practice, as any code that is using your class or function may unknowingly pass you values which could cause your code to crash.
Eg: A programmer once accidentally sent a NULL pointer to my code which had to do a deep copy of the object that the pointer pointed to.
But since I was cloning the pointed to instance in the copy constructor's initialization list, nobody could figure out why the program crashed.
The programmer said that I should've kept a check for a NULL pointer, but eventually we decided to keep the check on his end since we needed to preserve the efficiency of copying through the initialization list, which was faster.
So you can decide on placing checks depending on:
1. Efficiency of using a copy-ctor initialization list.
2. How well you've documented the input parameters and limitations of your functions/classes.
3. Whether your code could crash/yeild security issues because of malicious inputs
4. What kind of exception handling you need for your software.