出乎意料的'。'从包装表达到链 [英] Unexpected '.' from wrapped expression to chain

问题描述

我有这个计算总数的方法，其中一部分是在JS Lint中发出警告。我们正试图在工作中获得更清晰的JS Lint检查，所以我想看看是否有一种理性的解决方法可以解决这个问题。

  calculateTotal = function（）{
 var hours = parseFloat（$ hours.val（））; 
 var rate = parserFloat（$ rate.val（））; 
 var total =''; 
 
 if（！isNaN（小时）&&！isNaN（rate））{
 //这会引发错误。 
总= =（费率*小时）.toFixed（2）; 
} 
 
 $ total.val（总计）; 
} 
  

如果我执行以下操作，我可以避免此消息：

 总计=费率*小时; 
 total = total.toFixed（2）; 
  

我跳过它有点过于冗长，但这可能是最好的选择。

我检查了

抱歉，我无法在那里提供更多帮助。我认为有些地方（someExpression）.someMethod（）是权宜之计，但也要了解JSLint的来源。如果您有潜在的类型强制，请明确强制。

有趣的问题;谢谢你的询问。

I have this method that is calculating a total, and part of it is giving a warning in JS Lint. We're trying to get cleaner JS Lint inspections at work, so I want to see if there's a rational way to get around this that I'm not thinking of.

calculateTotal = function() {
    var hours = parseFloat($hours.val());
    var rate = parserFloat($rate.val());
    var total = '';

    if (!isNaN(hours) && !isNaN(rate)) {
        // This throws the error.
        total = (rate * hours).toFixed(2);
    }

    $total.val(total);
}

I can avoid the message if I do the following:

total = rate * hours;
total = total.toFixed(2);

It's a little too verbose for me to just jump at it, but it may be the best bet.

I checked out this question, and considered doing Number(rate * hours).toFixed(2), but that's (marginally) less performant, plus it would be a bad precedent to start with all of the warnings about using String() as stated in response to the accepted answer there.

This could be moot if my above attempt is the best way to get JS Lint to stop complaining, but I would like to hear from other people.

解决方案

TL;DR

JSLint is going to force you to move the toFixed() from behind of the parentheses. I'd suggest the least annoying place to move it is in the $total.val(total) assignment.

This lints as-is on JSLint.com:

/*jslint white:true, browser:true */
/*global $hours, $rate, $total */

var calculateTotal = function() {
    "use strict";
    var hours = parseFloat($hours.val());
    var rate = parseFloat($rate.val());
    var total;

    if (!isNaN(hours) && !isNaN(rate)) {
        // This throws the error.
        total = rate * hours;
    }

    $total.val(total.toFixed(2));  // moved `toFixed` to here
};

---

A little longer...

I tried it against the most recent version of JSLint, and it's borking at left_check in JSLint's code, here:

function left_check(left, right) {

// Warn if the left is not one of these:
//      e.b
//      e[b]
//      e()
//      identifier

    var id = left.id;
    if (
        !left.identifier &&
        (
            left.arity !== "binary" ||
            (id !== "." && id !== "(" && id !== "[")
        )
    ) {
        warn("unexpected_a", right);
        return false;
    }
    return true;
}

left is essentially (rate & hours) and right is . with toFixed the next token in this case.

As dangerous as it is to assume code function from comments, I think the comments tell us where JSLint is coming from -- It wants methods called only on objects, not on operations, including type coercions that often occur inside of them. It pretty much has to let you make "fluent" calls, where you chain methods, and the only valid things that can have method calls are...

• an object: e
• A property of an object: e.b
• A property in a collection: e[key]
• The return value of a function: e()

Just to double check, since your construction used to work in "old JSLint" (the last version before JSLint for ES6), I asked Douglas Crockford. He's pretty terse, but he did confirm JSLint is working as intended.

Sorry I can't be more help there. I think there are places where (someExpression).someMethod() is expedient, but understand where JSLint's coming from too. If you're going to have the potential for type coercion, coerce explicitly.

Interesting question; thanks for asking.

这篇关于出乎意料的'。'从包装表达到链的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！