Mã âm là gì?

340

Tôi đã đọc bài viết trên Wikipedia về Douglas McIlroy và tìm thấy một trích dẫn đề cập đến

"Người hùng thực sự của lập trình là người viết mã tiêu cực."

Điều đó nghĩa là gì?

terminology code-metrics

15

Một trong những ngày làm việc hiệu quả nhất của tôi là vứt bỏ 1000 dòng mã. - Ken Thompson

— Radu Potop

Liên quan: quora.com/How-many-lines-of-code-do-prof Professional-program ...

— Pacerier

501

Nó có nghĩa là giảm các dòng mã, bằng cách loại bỏ các dư thừa hoặc sử dụng các cấu trúc ngắn gọn hơn.

Xem ví dụ giai thoại nổi tiếng này từ nhóm nhà phát triển Apple Lisa ban đầu:

Khi nhóm Lisa đang cố gắng hoàn thiện phần mềm của họ vào năm 1982, các nhà quản lý dự án bắt đầu yêu cầu các lập trình viên gửi các biểu mẫu hàng tuần báo cáo về số lượng dòng mã họ đã viết. Bill Atkinson nghĩ rằng đó là ngớ ngẩn. Trong tuần mà anh ấy đã viết lại các thói quen tính toán vùng của QuickDraw để nhanh hơn sáu lần và ngắn hơn 2000 dòng, anh ấy đã đặt "-2000" vào biểu mẫu. Sau một vài tuần nữa, các nhà quản lý đã ngừng yêu cầu anh ta điền vào mẫu đơn, và anh ta vui vẻ tuân thủ.

— Thilo
nguồn

257

Sự hoàn hảo đạt được, không phải khi không còn gì để thêm, mà là khi không còn gì để lấy - Antoine de Saint-Exupéry

— systempuntoout

7

#LOC có phải là thước đo tốt về chất lượng mã không? Tôi có thể 'Giảm thiểu' bất kỳ mã C hoặc C ++ nào và giảm số lượng dòng đáng kể nhưng nó sẽ là một cơn ác mộng cần duy trì.

— JBRWilkinson

8

@systempuntout - và sau đó đã có Einsten "(Một lý thuyết khoa học) nên đơn giản nhất có thể, nhưng không đơn giản hơn"

— Jonathan Day

32

Không có gì chạy nhanh hơn, hoặc đáng tin cậy hơn hoặc yêu cầu bảo trì ít hơn so với mã không có ở đó. "Khi nghi ngờ, hãy bỏ nó ra!"

— TMN

4

@JBRWilkinson: Tôi muốn nói rằng có một "điểm ngọt" liên quan đến sự ngắn gọn của mã. Nói chung, ngắn hơn là tốt hơn, nhưng có một điểm khi mã có thể phát triển quá ngắn gọn và không dễ để giải mã cho một lập trình viên khác.

— GordonM

131

Có một câu trích dẫn của Bill Gates dọc theo các dòng đo năng suất của lập trình viên theo các dòng mã giống như đo lường tiến độ chế tạo máy bay theo trọng lượng.

Tôi muốn nói thêm rằng số liệu LỘC đã khuyến khích sử dụng các ngôn ngữ quá dài và cố tình phát minh lại bánh xe để đáp ứng hạn ngạch.

— Kyralessa
nguồn

30

Vâng, đó là vấn đề với bất kỳ loại số liệu. Ngay khi bạn sử dụng chúng để đánh giá hiệu suất của mọi người, họ sẽ bắt đầu chơi trò chơi số.

5

Có ai thực sự đã từng sử dụng LỘC làm chỉ số hiệu suất? Tôi chỉ thấy nó được sử dụng cho những thứ như "chúng ta đang nói về lỗi của dự án ở đây như thế nào?"

— Michael Borgwardt

5

@Michael: vâng. Không may là đúng vậy.

— Michael Petrotta

4

Có phải chúng ta đang nói về cùng một Bill G. người có một công ty mà theo phép ẩn dụ đó tạo ra 10000 máy bay phản lực GTON? :)

— Daniel Mošmondor

37

Một lập trình viên đã viết mã cho các máy tính trên tàu của Space Shuttle nói với tôi rằng anh ta phải tính đến trọng lượng của phần mềm! Phần mềm là có thật (tiền đã được trả cho nó); đó là trên tàu con thoi; trọng lượng của tất cả mọi thứ được tải trên tàu con thoi phải được tính. Ví dụ đầu tiên về đo năng suất lập trình viên theo trọng số của mã. (Không được phép, vì vậy anh ấy đã chỉ định 0,00001 gram và tất cả đều thỏa đáng.)

— Mark Lutton

118

Khi tôi học cấp ba - và vâng, chúng tôi đã có máy tính từ những năm 70, mặc dù chúng tôi phải làm cho chúng ra khỏi da động vật bằng dao đá - một trong những giáo viên toán đã tổ chức một cuộc thi lập trình. Các quy tắc là chương trình chiến thắng sẽ là chương trình tạo ra đầu ra chính xác và có sản phẩm nhỏ nhất về dòng thời gian chạy mã. Nghĩa là, nếu chương trình của bạn mất, hãy nói 100 dòng mã và chạy trong 5 giây, điểm của bạn là 500. Nếu người khác viết 90 dòng mã và chạy trong 6 giây, điểm của anh ta là 540. Điểm thấp sẽ thắng, như golf.

Nó đánh tôi như một hệ thống tính điểm tuyệt vời, bổ ích cho cả sự đồng nhất và hiệu suất.

Nhưng mục nhập về mặt kỹ thuật đáp ứng các tiêu chí chiến thắng đã bị loại. Vấn đề là in một danh sách tất cả các số nguyên tố nhỏ hơn 100. Mục không đủ tiêu chuẩn đã diễn ra như thế này (hầu hết các sinh viên đã sử dụng BASIC trước đó):

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

Học sinh đã viết bài viết đó chỉ ra rằng nó không chỉ ngắn và rất hiệu quả, mà thuật toán nên rõ ràng đối với bất kỳ ai có kiến thức lập trình tối thiểu, làm cho chương trình có khả năng duy trì cao.

— Jay
nguồn

10

Thêm bằng chứng cho thấy việc đếm các dòng mã là một số liệu rất dễ chơi :-)

44

Chương trình BASIC đó thật tuyệt vời! Thật khó chịu khi giáo viên bị loại khỏi chương trình. Rốt cuộc, các bảng tra cứu (mà chương trình có phần giống với) chắc chắn có thể được tìm thấy trong lập trình trong thế giới thực.

— Noctis Skytower

6

Một giáo viên thông thái có thể đã chấp nhận chương trình BASIC này và sử dụng nó để làm nổi bật tầm quan trọng của việc đạt được SRS đúng. Nhắc nhở tôi về một huấn luyện viên bóng chày đã rất thất vọng với đội của anh ấy rằng để chỉ cho họ cách chơi, anh ấy đã cầm gậy, đánh ba cú liên tiếp và không chịu thua kém, anh ấy hét lên với đội của anh ấy "Xem! ***** đang chơi. Bây giờ hãy cầm gậy và chơi đúng cách! ". Cũng nhắc nhở tôi về người đã viết "sáng tạo đã nhìn thấy người sáng tạo và đỏ mặt" và giành chiến thắng trong cuộc thi tiểu luận về 'rượu vang'.

— Nav

3

@Nav: Nhắc tôi về một câu chuyện tương tự bắt đầu theo cùng một cách. Sau đó, huấn luyện viên ném một quả bóng trong không khí, đu và bỏ lỡ. Anh lại ném nó lên không trung, đung đưa và bỏ lỡ. Anh ta ném nó lên không trung lần thứ ba, đung đưa và bỏ lỡ. Sau đó, anh ấy nói với đội, "Xem nào, đó là cách bạn nên ném bóng!" (Tôi không biết câu chuyện này có thể liên quan gì đến phát triển phần mềm.)

— Jay

13

Tôi sẽ rất buồn nếu tôi bị loại vì điều này. Một vấn đề xác định xứng đáng là một giải pháp xác định, phải không? Khi tôi viết ứng dụng 'Hello World', tôi không mã hóa nó để kiểm tra xem tôi có đánh vần đúng 'Xin chào' không.

— Kirk Broadhurst

34

Đó là miệng lưỡi. Nếu bạn phải trả $ N cho mỗi dòng mã hóa trung bình, thì mã hóa "dòng âm" chắc chắn là người chiến thắng.

Điều này có nghĩa, như lời khuyên thực tế, rằng mã nhỏ hoàn thành công việc, tốt hơn nhiều so với mã lớn làm điều tương tự, tất cả những thứ khác đều bằng nhau.

— Baxter
nguồn

2

Tôi thấy bạn đến từ đâu, nhưng mã dấu chân nhỏ gọn, dễ hiểu ít khi đạt được trong một lần. Nó thường được viết để nó hoạt động (nhiều dòng), tối ưu hóa tốc độ (ít dòng hơn một chút) và tối ưu hóa để bảo trì / dễ đọc (vẫn ít dòng hơn). Chi phí thực sự với lợi tức đầu tư dài là bước thứ hai và thứ ba, do đó chúng thường bị bỏ qua hoàn toàn. Nó giống như "có giá rẻ, nhanh và tốt - bạn có thể chọn hai".

2

Trên thực tế, IME, tối ưu hóa để duy trì / khả năng đọc thực sự có thể làm tăng LỘC, vì việc viết lại mã để làm cho nó tự viết tài liệu hơn có xu hướng cũng làm cho nó dài dòng hơn.

1

@Visage: "... tất cả những thứ khác đều bằng nhau".

— Ira Baxter

vấn đề là, tôi nghĩ rằng tất cả những thứ khác không thể bằng nhau giữa mã ngắn gọn và mã dài dòng.

— Tomas Narros

Lý do dòng mã trung bình có giá $ N là vì trước tiên bạn dành thời gian để viết Xcác dòng. Sau đó, qua nhiều lần lặp lại, giảm sản phẩm cuối cùng theo Ydòng. Vì vậy, các (X-Y)dòng còn lại dường như rất tốn kém vì cuộc tàn sát của tái cấu trúc đã cắt đứt tất cả các hành trình.

27

Viết cùng một chương trình với ít mã hơn là mục tiêu cho tất cả mọi người.

Nếu một chương trình lấy 200 LỘC để mã hóa và tôi viết nó vào năm 150, tôi đã viết -50 LỘC. Vì vậy, tôi đã viết mã tiêu cực.

— LucaB
nguồn

3

Ngoài ra, viết ít LỘC có nghĩa là bạn có thể mắc ít lỗi hơn và dễ dàng phát hiện ra chúng

— LucaB

3

Không đúng với Haskell và các ngôn ngữ khác có thể bị nén thành nhiễu ngẫu nhiên. :)

— Macke

1

Chắc chắn, quan điểm của tôi không phải là "nén mã", mà là viết các thuật toán hiệu quả để thực hiện ít hơn LỘC :) +1 cho bạn nhận xét.

— LucaB

9

Câu trả lời của Thilo có lẽ chính xác nhất trong lịch sử, nhưng phép ẩn dụ "mã âm" cũng có thể bao gồm hiệu suất và sử dụng bộ nhớ - những nỗ lực bổ ích để trì hoãn việc thực hiện hoặc phân bổ một cái gì đó cho đến khi thực sự cần thiết.

Tâm lý "chần chừ trả tiền" này đã tạo ra những tiên đề truyền miệng như "Không làm gì luôn nhanh hơn làm gì đó", "Mã nhanh nhất là mã không bao giờ thực thi" và "Nếu bạn có thể tắt nó đủ lâu," bạn có thể không bao giờ phải làm điều đó "(đề cập đến việc trì hoãn các hoạt động đắt tiền cho đến khi thực sự cần thiết)

Một kỹ thuật để hiện thực hóa mã tiêu cực là thách thức các giả định và định nghĩa ban đầu về vấn đề. Nếu bạn có thể xác định lại vấn đề / miền đầu vào sao cho "vấn đề dính # 3" là không thể phân loại được, thì bạn không phải mất thời gian hoặc mã xử lý vấn đề dính # 3. Bạn đã loại bỏ mã bằng cách tối ưu hóa thiết kế.

— dthorpe
nguồn