Tại sao nên tránh các toán tử tăng ((++ ++)) và giảm dần (trực tiếp) trong JavaScript?

Một trong những mẹo cho công cụ jslint là:

++ và -
Các toán tử ++ (tăng) và - (giảm) đã được biết là đóng góp cho mã xấu bằng cách khuyến khích sự khó khăn quá mức. Chúng chỉ đứng thứ hai sau kiến ​​trúc bị lỗi trong việc kích hoạt virus và các mối đe dọa bảo mật khác. Có một tùy chọn plusplus cấm sử dụng các toán tử này.

Tôi biết rằng các cấu trúc PHP như thế $foo[$bar++]có thể dễ dàng dẫn đến các lỗi khác nhau, nhưng tôi không thể tìm ra cách nào tốt hơn để kiểm soát vòng lặp hơn là một while( a < 10 ) do { /* foo */ a++; }hoặc for (var i=0; i<10; i++) { /* foo */ }.

Là jslint làm nổi bật chúng bởi vì có một số ngôn ngữ tương tự thiếu cú pháp " ++" và " --" hoặc xử lý nó khác nhau, hoặc có những lý do khác để tránh " ++" và " --" mà tôi có thể bị thiếu?

Quan điểm của tôi là luôn luôn sử dụng ++ và - một mình trên một dòng, như trong:

i++;
array[i] = foo;

thay vì

array[++i] = foo;

Bất cứ điều gì ngoài điều đó có thể gây nhầm lẫn cho một số lập trình viên và chỉ là không đáng theo quan điểm của tôi. Đối với các vòng lặp là một ngoại lệ, vì việc sử dụng toán tử gia tăng là thành ngữ và do đó luôn rõ ràng.

Tôi thực sự bối rối bởi lời khuyên đó. Một phần trong tôi tự hỏi liệu nó có liên quan nhiều đến việc thiếu kinh nghiệm (nhận thức hay thực tế) với các lập trình viên javascript.

Tôi có thể thấy cách ai đó chỉ "hack" ở một số mã mẫu có thể phạm sai lầm vô tội với ++ và - nhưng tôi không hiểu tại sao một chuyên gia có kinh nghiệm sẽ tránh chúng.

Có một lịch sử trong C khi làm những việc như:

while (*a++ = *b++);

để sao chép một chuỗi, có lẽ đây là nguồn gốc của mánh khóe quá mức mà anh ta đang đề cập.

Và luôn có câu hỏi về cái gì

++i = i++;

hoặc là

i = i++ + ++i;

thực sự làm Nó được định nghĩa trong một số ngôn ngữ và trong ngôn ngữ khác không có gì đảm bảo điều gì sẽ xảy ra.

Bỏ qua những ví dụ đó, tôi không nghĩ có gì thành ngữ hơn vòng lặp for sử dụng ++ để tăng. Trong một số trường hợp, bạn có thể thoát khỏi vòng lặp foreach hoặc vòng lặp while kiểm tra một ống dẫn khác. Nhưng việc sửa mã của bạn để thử và tránh sử dụng tăng dần là vô lý.

Nếu bạn đọc JavaScript Các bộ phận tốt, bạn sẽ thấy rằng sự thay thế của Crockford cho i ++ trong vòng lặp for là i + = 1 (không phải i = i + 1). Điều đó khá sạch sẽ và dễ đọc, và ít có khả năng biến thành một thứ gì đó "khó hiểu".

Crockford đã không cho phép tự động tăng tốc và tự động phát hiện một tùy chọn trong jsLint. Bạn chọn có làm theo lời khuyên hay không.

Quy tắc cá nhân của riêng tôi là không làm bất cứ điều gì kết hợp với tự động hoặc tự động phát hiện.

Tôi đã học được từ nhiều năm kinh nghiệm trong C rằng tôi không bị tràn bộ đệm (hoặc chỉ số mảng ngoài giới hạn) nếu tôi tiếp tục sử dụng đơn giản. Nhưng tôi đã phát hiện ra rằng tôi sẽ bị tràn bộ đệm nếu tôi rơi vào thực tiễn "quá khó" khi làm những việc khác trong cùng một tuyên bố.

Vì vậy, đối với các quy tắc của riêng tôi, việc sử dụng i ++ làm gia số trong vòng lặp for là ổn.

Trong một vòng lặp, nó vô hại, nhưng trong một câu lệnh gán nó có thể dẫn đến kết quả không mong muốn:

var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7

Khoảng trắng giữa biến và toán tử cũng có thể dẫn đến kết quả không mong muốn:

a = b = c = 1; a ++ ; b -- ; c; console.log('a:', a, 'b:', b, 'c:', c)

Trong một đóng cửa, kết quả bất ngờ cũng có thể là một vấn đề:

var foobar = function(i){var count = count || i; return function(){return count++;}}

baz = foobar(1);
baz(); //1
baz(); //2


var alphabeta = function(i){var count = count || i; return function(){return ++count;}}

omega = alphabeta(1);
omega(); //2
omega(); //3

Và nó kích hoạt chèn dấu chấm phẩy tự động sau một dòng mới:

var foo = 1, bar = 2, baz = 3, alpha = 4, beta = 5, delta = alpha
++beta; //delta is 4, alpha is 4, beta is 6

nhầm lẫn preincrement / postincrement có thể tạo ra các lỗi off-by-one cực kỳ khó chẩn đoán. May mắn thay, chúng cũng hoàn thành không cần thiết. Có nhiều cách tốt hơn để thêm 1 vào một biến.

Người giới thiệu

• Trợ giúp về JSLint: Toán tử tăng và giảm

Hãy xem xét các mã sau đây

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[i++] = i++;
    a[i++] = i++;
    a[i++] = i++;

kể từ khi i ++ được đánh giá hai lần đầu ra là (từ trình gỡ lỗi vs2005)

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Bây giờ hãy xem xét các mã sau đây:

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = ++i;
    a[++i] = ++i;
    a[++i] = ++i;

Lưu ý rằng đầu ra là như nhau. Bây giờ bạn có thể nghĩ rằng ++ i và i ++ giống nhau. Họ không phải

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Cuối cùng hãy xem xét mã này

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = i++;
    a[++i] = i++;
    a[++i] = i++;

Đầu ra là:

    [0] 0   int
    [1] 1   int
    [2] 0   int
    [3] 3   int
    [4] 0   int
    [5] 5   int

Vì vậy, chúng không giống nhau, trộn cả hai kết quả trong hành vi không trực quan. Tôi nghĩ rằng các vòng lặp đều ổn với ++, nhưng xem ra khi bạn có nhiều biểu tượng ++ trên cùng một dòng hoặc cùng một hướng dẫn

Bản chất "trước" và "bài" của các toán tử tăng và giảm có thể có xu hướng gây nhầm lẫn cho những người không quen thuộc với chúng; đó là một cách mà họ có thể khó khăn

Theo quan điểm của tôi, "Rõ ràng luôn tốt hơn ngầm." Bởi vì tại một số điểm, bạn có thể bị nhầm lẫn với tuyên bố gia tăng này y+ = x++ + ++y. Một lập trình viên giỏi luôn làm cho mã của mình dễ đọc hơn.

Lý do quan trọng nhất để tránh ++ hoặc - là các toán tử trả về các giá trị và gây ra các tác dụng phụ cùng một lúc, khiến cho việc lập luận về mã trở nên khó khăn hơn.

Vì lợi ích của hiệu quả, tôi thích:

• ++ i khi không sử dụng giá trị trả về (không tạm thời)
• i ++ khi sử dụng giá trị trả về (không có gian hàng đường ống)

Tôi là một fan hâm mộ của ông Crockford, nhưng trong trường hợp này tôi phải không đồng ý. ++iít hơn 25% văn bản để phân tích cú pháp hơn i+=1 và rõ ràng hơn.

Tôi đã xem video của Douglas Crockford về điều này và lời giải thích của anh ấy về việc không sử dụng tăng và giảm là

1. Nó đã được sử dụng trong quá khứ trong các ngôn ngữ khác để phá vỡ các giới hạn của mảng và gây ra tất cả các cách cư xử xấu và
2. Rằng các nhà phát triển JS khó hiểu và thiếu kinh nghiệm hơn không biết chính xác những gì nó làm.

Đầu tiên các mảng trong JavaScript có kích thước động và vì vậy, hãy tha thứ cho tôi nếu tôi sai, không thể phá vỡ giới hạn của một mảng và truy cập dữ liệu không nên truy cập bằng phương thức này trong JavaScript.

Thứ hai, chúng ta có nên tránh những thứ phức tạp không, chắc chắn vấn đề không phải là chúng ta có cơ sở này mà vấn đề là có những nhà phát triển ngoài đó tuyên bố làm JavaScript nhưng không biết các nhà khai thác này hoạt động như thế nào ?? Nó là đủ đơn giản. value ++, đưa cho tôi giá trị hiện tại và sau biểu thức thêm một giá trị vào nó, giá trị ++, tăng giá trị trước khi đưa cho tôi giá trị đó.

Biểu thức như một ++ + ++ b, rất đơn giản để làm việc nếu bạn chỉ cần nhớ ở trên.

var a = 1, b = 1, c;
c = a ++ + ++ b;
// c = 1 + 2 = 3; 
// a = 2 (equals two after the expression is finished);
// b = 2;

Tôi cho rằng bạn chỉ cần nhớ ai phải đọc qua mã, nếu bạn có một nhóm biết về JS thì bạn không cần phải lo lắng. Nếu không thì bình luận nó, viết nó khác đi, vv Hãy làm những gì bạn phải làm. Tôi không nghĩ rằng tăng và giảm vốn đã xấu hoặc tạo ra lỗi, hoặc tạo lỗ hổng, có thể chỉ dễ đọc hơn tùy thuộc vào đối tượng của bạn.

Btw, tôi nghĩ Douglas Crockford dù sao cũng là một huyền thoại, nhưng tôi nghĩ rằng anh ta đã gây ra nhiều nỗi sợ hãi cho một nhà điều hành không xứng đáng với điều đó.

Tôi sống để được chứng minh là sai mặc dù ...

Một ví dụ khác, đơn giản hơn một số khác với giá trị gia tăng đơn giản của giá trị gia tăng:

function testIncrement1(x) {
    return x++;
}

function testIncrement2(x) {
    return ++x;
}

function testIncrement3(x) {
    return x += 1;
}

console.log(testIncrement1(0)); // 0
console.log(testIncrement2(0)); // 1
console.log(testIncrement3(0)); // 1

Như bạn có thể thấy, không nên sử dụng tăng / giảm sau khi trả về, nếu bạn muốn toán tử này ảnh hưởng đến kết quả. Nhưng lợi nhuận không "bắt" toán tử tăng / giảm sau:

function closureIncrementTest() {
    var x = 0;

    function postIncrementX() {
        return x++;
    }

    var y = postIncrementX();

    console.log(x); // 1
}

Tôi nghĩ các lập trình viên nên thành thạo ngôn ngữ họ đang sử dụng; sử dụng nó rõ ràng; và sử dụng nó tốt. Tôi không nghĩ họ nên làm tê liệt ngôn ngữ họ đang sử dụng. Tôi nói từ kinh nghiệm. Tôi đã từng làm việc theo nghĩa đen bên cạnh một cửa hàng Cobol nơi họ không sử dụng ELSE 'vì nó quá phức tạp'. Reductio quảng cáo vô lý.

Như đã đề cập trong một số câu trả lời hiện có (điều khó chịu là tôi không thể bình luận), vấn đề là x ++ ++ x đánh giá các giá trị khác nhau (trước so với sau khi tăng), không rõ ràng và có thể rất khó hiểu - nếu giá trị đó được sử dụng. cdmckay gợi ý khá khôn ngoan khi cho phép sử dụng toán tử gia tăng, nhưng chỉ theo cách mà giá trị trả về không được sử dụng, ví dụ như trên dòng riêng của nó. Tôi cũng sẽ bao gồm việc sử dụng tiêu chuẩn trong một vòng lặp for (nhưng chỉ trong câu lệnh thứ ba, có giá trị trả về không được sử dụng). Tôi không thể nghĩ ra một ví dụ khác. Bản thân tôi đã bị "cháy", tôi cũng muốn giới thiệu hướng dẫn tương tự cho các ngôn ngữ khác.

Tôi không đồng ý với tuyên bố rằng sự khắt khe quá mức này là do rất nhiều lập trình viên JS thiếu kinh nghiệm. Đây là loại văn bản chính xác điển hình của các lập trình viên "quá thông minh" và tôi chắc chắn rằng nó phổ biến hơn nhiều trong các ngôn ngữ truyền thống hơn và với các nhà phát triển JS có nền tảng về các ngôn ngữ như vậy.

Theo kinh nghiệm của tôi, ++ i hoặc i ++ chưa bao giờ gây nhầm lẫn ngoài lần đầu tiên tìm hiểu về cách thức hoạt động của toán tử. Đó là điều cần thiết cho các vòng lặp cơ bản nhất và trong khi các vòng lặp được dạy bởi bất kỳ khóa học trung học hoặc đại học nào được dạy bằng các ngôn ngữ mà bạn có thể sử dụng toán tử. Cá nhân tôi thấy làm một cái gì đó giống như những gì bên dưới để nhìn và đọc tốt hơn một cái gì đó với một ++ nằm trên một dòng riêng biệt.

while ( a < 10 ){
    array[a++] = val
}

Cuối cùng, đó là một sở thích về phong cách và không phải là bất cứ điều gì nữa, điều quan trọng hơn là khi bạn thực hiện điều này trong mã của mình, bạn phải nhất quán để những người khác làm việc trên cùng một mã có thể làm theo và không phải xử lý cùng chức năng theo các cách khác nhau .

Ngoài ra, Crockford dường như sử dụng i- = 1, điều mà tôi thấy khó đọc hơn --i hoặc i--

2cents của tôi là họ nên tránh trong hai trường hợp:

1) Khi bạn có một biến được sử dụng trong nhiều hàng và bạn tăng / giảm nó trong câu lệnh đầu tiên sử dụng nó (hoặc cuối cùng, hoặc thậm chí tệ hơn ở giữa):

// It's Java, but applies to Js too
vi = list.get ( ++i );
vi1 = list.get ( i + 1 )
out.println ( "Processing values: " + vi + ", " + vi1 )
if ( i < list.size () - 1 ) ...

Trong các ví dụ như thế này, bạn có thể dễ dàng bỏ lỡ rằng biến được tự động tăng / giảm hoặc thậm chí loại bỏ câu lệnh đầu tiên. Nói cách khác, chỉ sử dụng nó trong các khối rất ngắn hoặc trong đó biến xuất hiện trong khối chỉ trên một vài câu lệnh gần.

2) Trong trường hợp có nhiều ++ và - về cùng một biến trong cùng một câu lệnh. Thật khó để nhớ những gì xảy ra trong những trường hợp như thế này:

result = ( ++x - --x ) * x++;

Các bài kiểm tra và bài kiểm tra chuyên nghiệp hỏi về các ví dụ như trên và thực sự tôi đã vấp phải câu hỏi này trong khi tìm tài liệu về một trong số chúng, nhưng trong cuộc sống thực, người ta không nên buộc phải suy nghĩ nhiều về một dòng mã.

Fortran có phải là ngôn ngữ giống C không? Nó không có ++ cũng không -. Đây là cách bạn viết một vòng lặp :

     integer i, n, sum

      sum = 0
      do 10 i = 1, n
         sum = sum + i
         write(*,*) 'i =', i
         write(*,*) 'sum =', sum
  10  continue

Phần tử chỉ số i được tăng theo quy tắc ngôn ngữ mỗi lần qua vòng lặp. Ví dụ: nếu bạn muốn tăng thêm một thứ gì đó ngoài 1, hãy đếm ngược theo hai, cú pháp là ...

      integer i

      do 20 i = 10, 1, -2
         write(*,*) 'i =', i
  20  continue

Python có giống C không? Nó sử dụng phạm vi và danh sách hiểu và các cú pháp khác để bỏ qua nhu cầu tăng chỉ mục:

print range(10,1,-2) # prints [10,8.6.4.2]
[x*x for x in range(1,10)] # returns [1,4,9,16 ... ]

Vì vậy, dựa trên khám phá thô sơ này về chính xác hai lựa chọn thay thế, các nhà thiết kế ngôn ngữ có thể tránh ++ và - bằng cách dự đoán các trường hợp sử dụng và cung cấp một cú pháp thay thế.

Có phải Fortran và Python là một nam châm lỗi ít hơn so với các ngôn ngữ thủ tục có ++ và -? Tôi không có bằng chứng.

Tôi khẳng định rằng Fortran và Python giống như C vì tôi chưa bao giờ gặp ai đó thông thạo C, người không thể đoán chính xác 90% ý định của Fortran hoặc Python không bị che giấu.