Nhà phát triển có nên nhắm đến khả năng đọc hoặc hiệu suất trước không? [đóng cửa]


82

Thông thường, một nhà phát triển sẽ phải đối mặt với sự lựa chọn giữa hai cách khả thi để giải quyết một vấn đề - một cách dễ hiểu và dễ đọc, và một cách khác ít trực quan hơn, nhưng có thể hoạt động tốt hơn. Ví dụ, trong các ngôn ngữ dựa trên C, có hai cách để nhân một số với 2:

int SimpleMultiplyBy2(int x)
{
    return x * 2; 
}

int FastMultiplyBy2(int x)
{
    return x << 1;
}

Phiên bản đầu tiên đơn giản hơn để nhận cho cả người đọc kỹ thuật và không kỹ thuật, nhưng phiên bản thứ hai có thể hoạt động tốt hơn, vì dịch chuyển bit là một hoạt động đơn giản hơn phép nhân. (Hiện tại, hãy giả sử rằng trình tối ưu hóa của trình biên dịch sẽ không phát hiện ra điều này và tối ưu hóa nó, mặc dù đó cũng là một điều cần cân nhắc).

Là một nhà phát triển, điều nào sẽ tốt hơn nếu là một nỗ lực ban đầu?


Hơi chát. Câu hỏi hay về mối quan tâm của tất cả chúng ta đôi khi. +1
Inisheer

3
Ví dụ này rõ ràng là giả tạo và tầm thường. Bạn sẽ không thực sự có một hàm với hệ số được mã hóa cứng.
JohnMcG

1
Vấn đề là tôi thấy rất nhiều câu hỏi như "<có hoạt động tốt hơn <= không?" Đây là câu hỏi sai - câu hỏi đúng (đầu tiên) là câu thành ngữ hoặc thông thường, sau đó hãy lo lắng về hiệu suất.
JohnMcG 8/10/08

1
Đây là một trong những câu hỏi hay nhất mà tôi đã đọc trên stackoverflow. Điều này liên quan đến cách máy tính hoạt động, không chỉ dựa trên ngữ nghĩa của ngôn ngữ. +1
WolfmanDragon 8/10/08

2
@OutlawLemur Tôi biết điều đó. Nhưng một số người hỏi liệu có nên tốt hơn không, ví dụ: xây dựng các vòng lặp bằng cách sử dụng <hoặc <= (với giá trị so sánh được tăng trước trong trường hợp sau).
JohnMcG

Câu trả lời:


108

Bạn đã bỏ lỡ một.

Mã đầu tiên cho tính đúng đắn, sau đó để rõ ràng (cả hai thường được kết nối, tất nhiên!). Cuối cùng, và chỉ khi bạn có bằng chứng thực nghiệm mà bạn thực sự cần, bạn mới có thể xem xét việc tối ưu hóa. Tối ưu hóa sớm thực sự là xấu xa. Việc tối ưu hóa hầu như luôn khiến bạn tốn thời gian, tính rõ ràng, khả năng bảo trì. Bạn nên chắc chắn rằng mình đang mua thứ gì đó đáng giá với thứ đó.

Lưu ý rằng các thuật toán tốt hầu như luôn đánh bại việc điều chỉnh cục bộ. Không có lý do gì bạn không thể có mã chính xác, rõ ràng và nhanh chóng. Mặc dù vậy, bạn sẽ may mắn một cách phi lý khi đến đó bắt đầu tập trung vào việc `` nhanh ''.


Đây là câu trả lời tốt nhất ở đây. Chỉnh sửa thuật toán chứ không phải mã. Với những thay đổi tinh tế, tôi có thể làm cho jscript Sieve of Erastosthenes hoạt động tốt hơn một phiên bản C ++ giống hệt. (Không phải là Sieve of Atkins, phương pháp riêng của tôi.)
Peter Wone

2
Thật tệ là bạn không thể yêu thích câu trả lời. :)
Sandor Davidhazi 13/10/08

59

IMO phiên bản dễ đọc trước tiên, cho đến khi hiệu suất được đo lường và yêu cầu phiên bản nhanh hơn.


Tôi đồng ý. Năm ngoái, tôi đã triển khai một thành phần chính ngoài cơ sở mã Java phía máy chủ của công ty mình và đã cố gắng hết sức để làm cho nó có thể đọc được. Sau đó, hóa ra có các vấn đề về hiệu suất và đã thực hiện một số công việc làm lại thiết kế của nó dẫn đến một thứ gì đó hơi khó đọc hơn theo một số cách.
Ryan Delucchi 8/10/08

46

Lấy nó từ Don Knuth

Tối ưu hóa sớm là gốc rễ của mọi điều xấu (hoặc ít nhất là hầu hết) trong lập trình.


Câu nói không phải từ chính Don, mà là từ Hoare. Don chỉ làm cho nó phổ biến. Kiểm tra wikipedia.
kohlerm 8/10/08

1
Và đó là một trích dẫn có chọn lọc của một mệnh đề trong toàn bộ đoạn văn, có chứa một số tiêu chuẩn rất quan trọng.
Marquis of Lorne,

19

Khả năng đọc 100%

Nếu trình biên dịch của bạn không thể thực hiện tối ưu hóa "x * 2" => "x << 1" cho bạn - hãy tải xuống trình biên dịch mới!

Cũng nên nhớ rằng 99,9% thời gian chương trình của bạn được dành để chờ người dùng nhập, chờ truy vấn cơ sở dữ liệu và chờ phản hồi của mạng. Trừ khi bạn đang làm nhiều lần 20 bajillion, nó sẽ không gây chú ý.


8

Trong ví dụ đã cho của bạn, 99,9999% trình biên dịch hiện có sẽ tạo ra cùng một mã cho cả hai trường hợp. Điều này minh họa quy tắc chung của tôi - trước tiên hãy viết để dễ đọc và dễ bảo trì, và chỉ tối ưu hóa khi bạn cần.


Trình biên dịch C sẽ biên dịch thành một mã lắp ráp khác nhau cho hai ví dụ được hiển thị. Lệnh đầu tiên tạo một vòng lặp, trong khi lệnh thứ hai tạo một lệnh shift left. Điều này sẽ đúng với các trình biên dịch kiểu All C, vì tôi chưa thử nghiệm từng cái, nên tôi không thể đưa ra lời hứa nào về điều đó.
WolfmanDragon 8/10/08

Đối với ví dụ cụ thể này, chắc chắn. Có rất nhiều trường hợp đó không phải là, vì vậy câu hỏi chung vẫn là một trong những tốt
Mark Baker

@WolfmanDragon, bạn đang nói cái quái gì vậy? Tại sao "* 2" sẽ tạo ra một vòng lặp? Khi tôi thử nó với "gcc -O2 -s", tôi nhận được hướng dẫn addl trong cả hai trường hợp.
Paul Tomblin

1
Nếu trình biên dịch của bạn tạo một vòng lặp trong chức năng đó, tôi khuyên bạn nên lấy một trình biên dịch khác!
Martin Vilcans

8

Khả năng đọc chắc chắn. Đừng lo lắng về tốc độ trừ khi ai đó phàn nàn


8

Khả năng đọc.

Mã hóa cho hiệu suất có một loạt thách thức riêng. Joseph M. Người mới nói hay

Tối ưu hóa chỉ quan trọng khi nó quan trọng. Khi nó quan trọng, nó quan trọng rất nhiều, nhưng cho đến khi bạn biết rằng nó quan trọng, đừng lãng phí nhiều thời gian để làm điều đó. Ngay cả khi bạn biết nó quan trọng, bạn cần biết nó quan trọng ở đâu. Nếu không có dữ liệu hiệu suất, bạn sẽ không biết phải tối ưu hóa cái gì và có thể bạn sẽ tối ưu hóa sai thứ.

Kết quả sẽ tối nghĩa, khó viết, khó gỡ lỗi và khó bảo trì mã không giải quyết được vấn đề của bạn. Do đó, nó có nhược điểm kép là (a) tăng chi phí phát triển phần mềm và bảo trì phần mềm, và (b) hoàn toàn không ảnh hưởng đến hiệu suất.


5

Khả năng đọc. Thời gian để tối ưu hóa là khi bạn bắt đầu thử nghiệm beta. Nếu không, bạn sẽ không bao giờ thực sự biết mình cần dành thời gian cho việc gì.


5

Tôi sẽ đi đầu tiên để dễ đọc . Xem xét thực tế là với các loại ngôn ngữ được tối ưu hóa và các máy được tải cực lớn mà chúng ta có trong những ngày này, hầu hết các mã chúng ta viết theo cách có thể đọc được sẽ hoạt động tốt.

Trong một số trường hợp rất hiếm gặp, khi bạn khá chắc chắn rằng mình sẽ bị chai về hiệu suất (có thể là do một số trải nghiệm tồi tệ trong quá khứ) và bạn đã cố gắng tìm ra một số thủ thuật kỳ lạ có thể mang lại cho bạn lợi thế lớn về hiệu suất, bạn có thể thực hiện cái đó. Nhưng bạn nên nhận xét đoạn mã đó thật tốt, điều này sẽ giúp làm cho nó dễ đọc hơn.


4

Một yếu tố thường bị bỏ qua trong cuộc tranh luận này là lập trình viên mất thêm thời gian để điều hướng, hiểu và sửa đổi mã ít đọc hơn. Xem xét thời gian của một lập trình viên là một trăm đô la một giờ hoặc hơn, đây là một chi phí rất thực tế.
Bất kỳ mức tăng hiệu suất nào đều bị ảnh hưởng bởi chi phí bổ sung trực tiếp này trong quá trình phát triển.


4

Đặt một bình luận ở đó với một lời giải thích sẽ làm cho nó dễ đọc và nhanh chóng.

Nó thực sự phụ thuộc vào loại dự án và hiệu suất quan trọng như thế nào. Nếu bạn đang xây dựng một trò chơi 3D, thì thường có rất nhiều cách tối ưu hóa phổ biến mà bạn sẽ muốn thực hiện trong suốt quá trình đó và không có lý do gì để không (chỉ cần đừng quá sớm). Nhưng nếu bạn đang làm một điều gì đó khó khăn, hãy bình luận nó để bất kỳ ai nhìn vào nó sẽ biết làm thế nào và tại sao bạn đang gian xảo.


3

Câu trả lời tùy thuộc vào ngữ cảnh. Ví dụ, trong lập trình trình điều khiển thiết bị hoặc phát triển trò chơi, dạng thứ hai là một thành ngữ có thể chấp nhận được. Trong các ứng dụng kinh doanh, không quá nhiều.

Đặt cược tốt nhất của bạn là xem mã (hoặc trong các ứng dụng thành công tương tự ) để kiểm tra cách các nhà phát triển khác làm điều đó.


3

sử dụng << sẽ bởi một tối ưu hóa vi mô. Vì vậy, quy tắc của Hoare (không phải Knuts):

Tối ưu hóa sớm là gốc rễ của mọi điều xấu xa.

áp dụng và bạn chỉ nên sử dụng phiên bản dễ đọc hơn ngay từ đầu.

Đây là quy tắc IMHO thường bị lạm dụng như một cái cớ để thiết kế phần mềm không bao giờ có thể mở rộng hoặc hoạt động tốt.


3

Cả hai. Mã của bạn nên cân bằng cả hai; khả năng đọc và hiệu suất. Bởi vì bỏ qua một trong hai sẽ làm giảm ROI của dự án, mà cuối cùng thì chỉ số này là quan trọng đối với sếp của bạn.

Khả năng đọc kém dẫn đến khả năng bảo trì giảm, dẫn đến nhiều tài nguyên hơn dành cho bảo trì, dẫn đến ROI thấp hơn.

Hiệu suất kém dẫn đến giảm đầu tư và cơ sở khách hàng, dẫn đến ROI thấp hơn.


2

Cơ sở mã càng lớn thì khả năng đọc càng quan trọng. Cố gắng hiểu một số chức năng nhỏ không phải là quá tệ. (Đặc biệt là vì Tên phương pháp trong ví dụ cho bạn một manh mối.) Không quá tuyệt vời đối với một số đoạn mã uber hoành tráng được viết bởi một thiên tài cô độc, người vừa bỏ lập trình vì cuối cùng anh ta đã nhìn thấy đỉnh cao của khả năng phức tạp và đó là những gì anh ta chỉ đã viết cho bạn và bạn sẽ không bao giờ hiểu nó.


2

Nếu bạn lo lắng về khả năng đọc mã của mình, đừng ngần ngại thêm nhận xét để nhắc nhở bản thân về điều gì và tại sao bạn đang làm điều này.


1

Các bitshift so với nhân là một tối ưu hóa tầm thường mà lợi nhuận bên cạnh không có gì . Và, như đã được chỉ ra, trình biên dịch của bạn sẽ làm điều đó cho bạn. Ngoài ra, dù sao đi nữa, mức tăng là không thể bỏ qua cũng như CPU ​​mà lệnh này chạy trên đó.

Mặt khác, nếu bạn cần thực hiện tính toán nghiêm túc, bạn sẽ yêu cầu cấu trúc dữ liệu phù hợp. Nhưng nếu vấn đề của bạn phức tạp, tìm hiểu về vấn đề đó là một phần của giải pháp. Như một minh họa, hãy xem xét việc tìm kiếm số ID trong một mảng 1000000 đối tượng chưa được sắp xếp. Sau đó, xem xét lại việc sử dụng cây nhị phân hoặc bản đồ băm.

Nhưng các tối ưu hóa như n << C thường không thể sử dụng được và không thể thay đổi thành bất kỳ lúc nào. Làm cho mã có thể đọc được thì không.


1

Nó phụ thuộc vào nhiệm vụ cần được giải quyết. Thông thường, khả năng dễ đọc là chất nhập khẩu hơn, nhưng vẫn có một số nhiệm vụ khi bạn nghĩ đến hiệu suất ngay từ đầu. Và bạn không thể chỉ dành một ngày để lập hồ sơ và tối ưu hóa sau khi mọi thứ hoạt động hoàn hảo, vì bản thân việc tối ưu hóa có thể yêu cầu viết lại một phần đủ của mã từ đầu. Nhưng nó không phải là phổ biến ngày nay.


1

Bạn phải luôn tối ưu hóa tối đa, hiệu suất luôn được tính. Lý do chúng ta có bloatware ngày nay là hầu hết các lập trình viên không muốn thực hiện công việc tối ưu hóa.

Đã nói rằng, bạn luôn có thể đưa các nhận xét vào nơi mà mã hóa trơn tru cần được làm rõ.


Tôi đồng ý ở một mức độ nhất định. Tôi không nghĩ rằng bạn nên đưa vào các tối ưu hóa vi mô như câu hỏi ban đầu đã nêu. Bạn phải thiết kế hệ thống của mình theo cách mà bạn sử dụng tài nguyên một cách tối ưu. Có nhiều hiệu suất hơn để đạt được trong lĩnh vực đó.
Erik van Brakel 13/10/08

Chúng ta có bloatware ngày nay, nhưng tôi không đổ lỗi cho việc thiếu tối ưu hóa. Tôi đổ lỗi cho việc thiết kế quá mức, bắt ruồi bằng bazooka, xây dựng tàu biển khi chỉ cần thuyền chèo. Sau đó, tất nhiên nó rất nguy hiểm.
Mike Dunlavey 09/08/08

Tôi đồng ý với bạn rằng tối ưu hóa thiết kế là ưu tiên hàng đầu. Tôi cũng sẽ nói rằng thái độ tương tự nên được áp dụng cho tất cả các cấp của quy trình kỹ thuật phần mềm. Nếu bạn không bận tâm đến việc tối ưu hóa ở cấp độ mã, thì có lẽ bạn cũng thiếu sót trong quá trình thiết kế.
Lance Roberts

1

Sẽ không có ích gì khi tối ưu hóa nếu bạn không biết những điểm nghẽn của mình. Bạn có thể đã tạo ra một chức năng hiệu quả đáng kinh ngạc (thường là ở mức độ dễ đọc) chỉ để tìm thấy phần mã đó hầu như không bao giờ chạy hoặc nó dành nhiều thời gian hơn cho việc truy cập đĩa hoặc cơ sở dữ liệu hơn là bạn sẽ tiết kiệm được các bit nhỏ. Vì vậy, bạn không thể tối ưu hóa vi mô cho đến khi bạn có thứ gì đó để đo lường và sau đó, bạn cũng có thể bắt đầu để dễ đọc. Tuy nhiên, bạn nên lưu ý đến cả tốc độ và sự dễ hiểu khi thiết kế kiến ​​trúc tổng thể, vì cả hai đều có thể có tác động lớn và khó thay đổi (tùy thuộc vào phong cách mã hóa và các phép đo tổng thể).


1

Người ta ước tính rằng khoảng 70% chi phí của phần mềm là trong việc bảo trì. Khả năng đọc giúp hệ thống dễ bảo trì hơn và do đó làm giảm chi phí của phần mềm trong suốt thời gian sử dụng.

Có những trường hợp mà hiệu suất quan trọng hơn khả năng đọc, điều đó nói rằng chúng rất ít và xa.

Trước khi loại bỏ khả năng đọc, hãy nghĩ "Tôi (hoặc công ty của bạn) có sẵn sàng đối phó với chi phí bổ sung mà tôi đang thêm vào hệ thống bằng cách làm điều này không?"


1

Tôi không làm việc tại google vì vậy tôi sẽ đi theo lựa chọn xấu. (tối ưu hóa)

Trong Chương 6 của "Những viên ngọc trai lập trình" của Jon Bentley, ông mô tả cách một hệ thống đã tăng tốc gấp 400 lần bằng cách tối ưu hóa ở 6 ​​cấp độ thiết kế khác nhau. Tôi tin rằng bằng cách không quan tâm đến hiệu suất ở 6 cấp độ thiết kế này, những người triển khai hiện đại có thể dễ dàng đạt được mức độ chậm 2-3 bậc trong chương trình của họ.


1

Như hầu hết mọi người đã nói trong câu trả lời của họ, tôi ủng hộ tính dễ đọc . 99 trong số 100 dự án tôi thực hiện không có yêu cầu về thời gian phản hồi khó khăn, vì vậy đó là một lựa chọn dễ dàng.

Trước khi bạn bắt đầu viết mã, bạn nên biết câu trả lời. Một số dự án có các yêu cầu về hiệu suất nhất định, chẳng hạn như 'cần có thể chạy tác vụ X trong Y (milli) giây'. Nếu đúng như vậy, bạn có một mục tiêu để hướng tới và bạn biết khi nào mình phải tối ưu hóa hay không. (hy vọng) điều này được xác định ở giai đoạn yêu cầu của dự án của bạn, không phải khi viết mã.

Khả năng đọc tốt và khả năng tối ưu hóa sau này là kết quả của thiết kế phần mềm phù hợp. Nếu phần mềm của bạn là thiết kế tốt, bạn sẽ có thể tách biệt các phần của phần mềm và viết lại chúng nếu cần mà không làm hỏng các phần khác của hệ thống. Bên cạnh đó, hầu hết các trường hợp tối ưu hóa thực sự mà tôi gặp phải (bỏ qua một số thủ thuật cấp thấp thực sự, đó là sự ngẫu nhiên) là thay đổi từ thuật toán này sang thuật toán khác hoặc lưu dữ liệu vào bộ nhớ thay vì đĩa / mạng.


1

Khả năng đọc là mục tiêu ĐẦU TIÊN.

Vào những năm 1970, quân đội đã thử nghiệm một số kỹ thuật "mới" của phát triển phần mềm (thiết kế từ trên xuống, lập trình có cấu trúc, nhóm lập trình trưởng, để xác định một số kỹ thuật trong số này tạo ra sự khác biệt có ý nghĩa thống kê.

CHỈ CÓ kỹ thuật tạo ra sự khác biệt có ý nghĩa thống kê trong quá trình phát triển là ...

THÊM DÒNG BLANK vào mã chương trình.

Việc cải thiện khả năng đọc trong mã hướng đối tượng trước, có cấu trúc trước đó là kỹ thuật duy nhất trong các nghiên cứu này giúp cải thiện năng suất.

==============

Việc tối ưu hóa chỉ nên được giải quyết khi toàn bộ dự án đã được kiểm tra đơn vị và sẵn sàng cho thiết bị đo đạc. Bạn không bao giờ biết bạn cần tối ưu hóa mã ở đâu.

Trong cuốn sách mang tính bước ngoặt của họ, Kernigan và Plauger vào cuối năm 1970 CÔNG CỤ PHẦN MỀM (1976) và CÔNG CỤ PHẦN MỀM TRONG PASCAL (1981) đã chỉ ra các cách tạo các chương trình có cấu trúc bằng cách sử dụng thiết kế từ trên xuống. Họ đã tạo ra các chương trình xử lý văn bản: trình soạn thảo, công cụ tìm kiếm, trình xử lý trước mã.

Khi chức năng định dạng văn bản hoàn chỉnh được INSTRUMENTED, họ phát hiện ra rằng phần lớn thời gian xử lý được dành cho ba quy trình thực hiện nhập và xuất văn bản (Trong cuốn sách gốc, các hàm io chiếm 89% thời gian. Trong cuốn sách pascal, các hàm này tiêu thụ 55%!)

Họ đã có thể tối ưu hóa BA quy trình này và tạo ra kết quả là tăng hiệu suất với thời gian và chi phí phát triển hợp lý, có thể quản lý được.


1

Khả năng đọc trước tiên. Nhưng điều quan trọng hơn cả là tính đơn giản, đặc biệt là về cấu trúc dữ liệu.

Tôi nhớ về một sinh viên đang thực hiện một chương trình phân tích tầm nhìn, người không thể hiểu tại sao nó lại quá chậm. Anh ấy chỉ đơn thuần tuân theo thực tiễn lập trình tốt - mỗi pixel là một đối tượng và nó hoạt động bằng cách gửi thông điệp đến các hàng xóm của nó ...

kiểm tra cái này


1

Nếu không có khả năng đọc, bạn sẽ rất khó cải thiện hiệu suất khi thực sự cần.

Hiệu suất chỉ nên được cải thiện khi nó là một vấn đề trong chương trình của bạn, có nhiều chỗ sẽ là một cổ chai hơn là cú pháp này. Giả sử bạn đang cố gắng cải thiện 1ns trên << nhưng bỏ qua thời gian IO 10 phút đó.

Ngoài ra, về khả năng đọc, một lập trình viên chuyên nghiệp phải có thể đọc / hiểu các thuật ngữ khoa học máy tính. Ví dụ, chúng ta có thể đặt tên cho một phương thức là enqueue thay vì phải nói putThisJobInWorkQueue.


Trong khi tôi đồng ý, tôi nghĩ bạn có một ví dụ kém. Ví dụ, là một người không biết gì về codebase của bạn, enqueue đối với tôi ít có ý nghĩa hơn. Tôi không muốn biết làm thế nào, tôi muốn biết những gì. Ví dụ bạn đưa ra cho biết điều gì tốt hơn nhiều.
Shaun Sweet

0

Viết cho dễ đọc trước tiên, nhưng mong đợi người đọc là lập trình viên . Bất kỳ lập trình viên nào đáng giá muối của mình đều phải biết sự khác biệt giữa phép nhân và phép dịch chuyển bit, hoặc có thể đọc toán tử bậc ba nơi nó được sử dụng thích hợp, có thể tra cứu và hiểu một thuật toán phức tạp (bạn đang bình luận mã của mình đúng không? ), Vân vân.

Tất nhiên, việc tối ưu hóa quá mức ban đầu khá tệ khi khiến bạn gặp rắc rối sau này khi bạn cần cấu trúc lại, nhưng điều đó không thực sự áp dụng cho việc tối ưu hóa các phương pháp, khối mã hoặc câu lệnh riêng lẻ.


0

Tôi muốn nói là đi để dễ đọc.

Nhưng trong ví dụ đã cho, tôi nghĩ rằng phiên bản thứ hai đã đủ đọc được, vì tên của hàm nói lên chính xác những gì đang diễn ra trong hàm.

Nếu chúng ta luôn luôn có các chức năng cho chúng ta biết, những gì chúng làm ...


0

Một giờ xử lý tốn bao nhiêu tiền?

Một giờ lập trình viên tốn bao nhiêu tiền?


một giờ thời gian của người dùng cuối tốn bao nhiêu? bây giờ rất hữu ích bởi số lượng người dùng.
gbjbaanb 8/10/08

gbjbaanb: Chính xác là suy nghĩ của tôi. Nhận xét của Andy chỉ phù hợp với các dịch vụ mà người dùng cuối sẽ không bao giờ nhìn thấy, và thậm chí sau đó nó khó có thể so sánh tốt.
Erik van Brakel 13/10/08

0

IMHO cả hai điều không có gì để làm. Trước tiên, bạn nên tìm mã hoạt động, vì điều này quan trọng hơn hiệu suất hoặc nó đọc tốt như thế nào. Về khả năng đọc: mã của bạn phải luôn có thể đọc được trong mọi trường hợp.

Tuy nhiên, tôi không hiểu tại sao mã không thể đọc được và cung cấp hiệu suất tốt cùng một lúc. Trong ví dụ của bạn, phiên bản thứ hai có thể đọc được như phiên bản đầu tiên đối với tôi. Điều gì ít đọc được về nó? Nếu một lập trình viên không biết rằng chuyển sang trái giống như nhân với lũy thừa hai và chuyển sang phải cũng giống như chia cho lũy thừa của hai ... tốt, thì bạn có nhiều vấn đề cơ bản hơn khả năng đọc thông thường.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.