Tại điểm nào là điều cấm kỵ để có vòng lặp trong vòng lặp?


23

Chỉ tò mò thôi. Cái tôi thích nhất từng có là một vòng lặp for trong vòng lặp for, bởi vì sau khi đọc nó từ Linus Torvalds:

Tab có 8 ký tự và do đó, thụt lề cũng là 8 ký tự. Có những chuyển động dị giáo cố gắng làm cho các ký tự 4 (hoặc thậm chí là 2!) Sâu, và đó là giống như cố gắng xác định giá trị của PI là 3.

Đặt vấn đề: Toàn bộ ý tưởng đằng sau thụt đầu dòng là xác định rõ nơi một khối điều khiển bắt đầu và kết thúc. Đặc biệt là khi bạn đã nhìn vào màn hình của mình trong 20 giờ liền, bạn sẽ thấy việc thụt lề hoạt động dễ dàng hơn nhiều nếu bạn có những vết lõm lớn.

Bây giờ, một số người sẽ cho rằng việc có các ký tự 8 ký tự làm cho mã di chuyển quá xa sang phải và khiến cho việc đọc trên màn hình thiết bị đầu cuối 80 ký tự trở nên khó khăn. Câu trả lời cho điều đó là nếu bạn cần nhiều hơn 3 cấp độ thụt đầu dòng, dù sao bạn cũng bị vặn và nên sửa chương trình của mình.

https://www.kernel.org/doc/Documentation/CodingStyle

Tôi nghĩ rằng đó là một thực tế không thể chấp nhận được đối với tôi để đi đến lớp lặp thứ ba và sẽ cơ cấu lại mã của tôi (Chủ yếu là Qt).

Linus có nói đùa không?

Nó phụ thuộc vào ngôn ngữ hoặc ứng dụng?

Có một số điều hoàn toàn cần ba hoặc nhiều cấp độ vòng lặp?


8
Tôi bối rối tại sao bạn nhảy từ thụt vào cấp độ vòng lặp? Bạn có một trích dẫn lớn thảo luận về thụt đầu dòng và đột nhiên từ đó xuất hiện một câu hỏi về các vòng lặp lồng nhau.
Pieter B

5
Linus có lẽ không (chỉ) nói đùa trong phần đó, nhưng lưu ý rằng đây chỉ là một hướng dẫn kiểu và cùng một hướng dẫn kiểu nhấn mạnh rằng "Phong cách mã hóa hạt nhân là siêu đơn giản", nghĩa là nhiều hơn các kiểu khác.

5
@Akiva Bạn không thể đi qua ma trận 4 chiều mà không có 4 vòng lặp lồng nhau. Tôi thấy thật điên rồ khi ai đó sẽ giới hạn số lượng các vòng lặp lồng nhau mà bạn có thể có. Linus rõ ràng là rất chung chung và bạn không nên lấy mọi thứ bạn đọc làm kinh thánh.
Alternatex

9
@Alternatex Rằng bạn cần 4 vòng không có nghĩa là chúng phải được lồng vào nhau theo từ vựng . Một điều khá rõ ràng từ trích dẫn rằng chúng ta đang nói về cách tổ chức mã chứ không phải về việc thực thi.

4
@delnan Tôi không nói rằng 4 vòng lặp lồng nhau rất dễ nhìn và tôi biết có nhiều cách khác để làm điều đó nhưng tôi thấy thật ngớ ngẩn khi OP hiểu những lời của Linus theo nghĩa đen. Cấp độ thụt thứ 4 = ngày tận thế. Hãy cho tôi một break.
Alternatex

Câu trả lời:


19

Hạt nhân thích các thuật toán đơn giản

Mặc dù một loạt các thuật toán có thể yêu cầu các vòng lặp lồng nhau sâu trong các vòng lặp, trong bối cảnh hạt nhân Linux (trong đó trích dẫn đã được nói), bạn thường cần phản hồi nhanh chóng theo thời gian thực. Trong bối cảnh đó, lồng sâu là một mùi có thể chỉ ra rằng dòng mã quá phức tạp đối với miền này và có thể cần phải thay đổi vì đặc điểm thực thi của nó, không phải là vấn đề dễ đọc hoặc thụt lề.

Hơn nữa, Linux kernel là khác biệt so với hầu hết các mã ứng dụng như đối với các yêu cầu của auditability và thử nghiệm - và do đó sẽ thích không có một 4+ mức thuật toán lồng nhau trong một chức năng duy nhất. Rõ ràng là phải xem những gì mỗi đoạn mã thực hiện chính xác và chi tiết, bao gồm tất cả các dòng điều khiển và trường hợp cạnh có thể. Mã lồng sâu ngăn cản mà.


Vì vậy, bạn có nghĩ rằng với các ngôn ngữ cấp thấp hơn như C, các vòng lặp lồng nhau sâu thường là becausecác dự án cấm kỵ hơn sử dụng các ngôn ngữ cấp thấp hơn được hưởng lợi từ một kiểu mã hóa tập trung vào các thuật toán đơn giản hơn?
Akiva

4
@Akiva Tôi sẽ không buộc nó với các ngôn ngữ cấp thấp hơn hoặc C như vậy, mà là với miền mã. Tôi nghĩ rằng các hướng dẫn tương tự sẽ áp dụng cho bất kỳ ngôn ngữ nào khi viết mã phải mạnh mẽ, tập trung bảo mật và có thể kiểm toán được bằng chi phí của những thứ khác. Ví dụ, một thư viện mã hóa được viết bằng Java hoặc Haskell cũng nên được viết theo kiểu giữ mọi thứ đơn giản nhất có thể, hạn chế lồng và cố gắng tách mọi thứ thành các phần có thể dễ dàng phân tích với tất cả các hậu quả có thể có của chúng.
Peteris

Một nhận xét / câu trả lời rất sâu sắc và hữu ích. Chỉ tò mò; loại dự án nào được thực hiện ngày hôm nay sử dụng ngôn ngữ cấp thấp, sẽ không tập trung vào việc mạnh mẽ, có thể kiểm toán và bảo mật?
Akiva

7
Ví dụ: @Akiva, mã máy học nơi bạn có thể muốn sử dụng C chỉ vì lý do hiệu suất nhưng không quan tâm nhiều đến sự mạnh mẽ hoặc bảo mật vì nó sẽ được chạy nội bộ trong các điều kiện được kiểm soát. Ngoài ra, thực hiện chức năng kinh doanh đơn giản trên các vi điều khiển nhúng nhỏ - trong thực tế, điều này thường có một doanh nghiệp như tập trung vào các tính năng và tốc độ phát triển với chi phí chất lượng và bảo mật, nhưng sử dụng ngôn ngữ cấp thấp.
Peteris

49

Ở một mức độ nào đó, tôi đã dừng việc trích dẫn nghiêm túc này tại "Tab có 8 ký tự" . Điểm chung của các trình lập bảng là chúng không phải là một số ký tự cố định (nếu có, một tab là một ký tự). Thật là một tải tosh. Tương tự như vậy, tôi không hoàn toàn tin rằng việc thiết lập một quy tắc khó và nhanh là "ba cấp độ thụt" là lành mạnh (nhiều như đặt ra một quy tắc khó và nhanh cho bất cứ điều gì là lành mạnh).

Tuy nhiên, hạn chế mức độ của bạn của thụt đầu dòng nói chung một đề nghị hợp lý, và không phải một mà nên đến như là một sự ngạc nhiên cho bạn.

Cuối cùng, nếu chương trình của bạn cần ba cấp độ lặp, đó là những gì chương trình của bạn cần . Tinh thần của trích dẫn không phải là làm giảm bớt một cách kỳ diệu yêu cầu đó từ dự án của bạn, mà là đưa logic vào các chức năng và loại để mã của bạn trở nên chặt chẽ và biểu cảm hơn.

Điều này chỉ phản hồi lại theo cùng một hướng dẫn được đưa ra ở trên về mức độ thụt đầu dòng. Đó là về cách bạn cấu trúc mã của mình và giữ cho nó dễ đọc, có thể duy trì và vui vẻ để sửa đổi trong nhiều năm tới.


6
Tôi tin rằng "tuyên bố" rằng các tab có 8 ký tự cụ thể trong bối cảnh phát triển kernel. Báo giá này được lấy từ một hướng dẫn mã hóa cho một dự án cụ thể và không nhằm mục đích trở thành một hướng dẫn sử dụng chung, và do đó nó được dự kiến ​​sẽ khá được quan tâm.
Lie Ryan

6
@LieRyan: Sau đó, nó vẫn là tosh - một hướng dẫn mã hóa cho bất cứ điều gì không có doanh nghiệp chỉ ra rằng tôi đặt các tab của mình rộng bao nhiêu! Nhưng tôi nghi ngờ Linus biết điều đó.
Cuộc đua nhẹ nhàng với Monica

6
và tất nhiên, nó phụ thuộc vào ngôn ngữ - trong c #, thông thường là bạn thụt vào trong không gian tên, trong lớp và trong phương thức của bạn .. bạn đã ở mức 3 mức thụt trước khi bạn nói về các thân câu lệnh điều khiển thụt lề.
PeterL

3
@LightnessRacesinOrbit Tôi diễn giải nhận xét "Tab là 8 ký tự" không có nghĩa là bạn phải xem các tab rộng 8 inch trong trình chỉnh sửa của mình, nhưng với mục đích của các quy tắc khác trong hướng dẫn kiểu (chẳng hạn như "Giới hạn về độ dài của dòng là 80 cột và đây là giới hạn được ưu tiên mạnh mẽ. ") người ta phải coi các tab là 8 cột, điều này cũng liên quan đến các quy tắc khác liên quan đến căn chỉnh đối số trong các lệnh gọi hàm. Một lần nữa, tôi không nghĩ rằng mục đích của dòng đó là buộc bạn phải xem các tab theo cách đó, tôi đã thực hiện vá nhân trước đó với 4 tab rộng và kết thúc mã ở cuối.
Vality

4
@underscore_d: Có vẻ như tôi đã sai: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.- 6 đoạn trích từ trích dẫn trong OP.
slebetman

16

Điểm này giống như đối với bất kỳ cấu trúc kiểm soát luồng nào: nếu mã khó hiểu, bạn cần cấu trúc lại nó. Nếu bạn đang thực hiện một số thao tác đơn giản của một mảng đa chiều, thì việc có các vòng lặp được lồng năm hoặc sáu sâu có thể là phù hợp, miễn là logic trong vòng lặp trong cùng là đơn giản. Tuy nhiên, nếu bạn đang xử lý một số logic kinh doanh phức tạp và phần thân của vòng lặp của bạn là hàng chục dòng trở lên, thì có lẽ bạn sẽ không muốn lồng sâu hơn một vòng lặp đó. Bạn có thể thử tính toán độ phức tạp theo chu kỳ của mã, nhưng điều thực sự xảy ra là khả năng đọc và khả năng duy trì của mã được đề cập.


11
Chính xác. Thật quá dễ dàng để đề nghị Torvalds là một kẻ ngốc. (Tất nhiên là anh ấy.) Anh ấy có thể quá cứng nhắc với sở thích của bạn, nhưng anh ấy đang mô tả một mối quan tâm phát triển thực sự gây ra vấn đề thực sự. Bạn không cần phải làm chính xác những gì anh ấy nói, nhưng bạn nên nghĩ về lý do tại sao anh ấy nói điều đó.
Scant Roger

7
@ScantRoger Thật ra, câu nói đó của Torvalds chỉ nghe có vẻ quá cứng nhắc nếu bạn không có được khiếu hài hước của anh ấy. Như tôi nhớ, trước đó trong cùng một tài liệu, anh ấy đề nghị in ra một bản sao của các hướng dẫn về phong cách mã hóa GNU, chỉ để ghi chúng trong một số nghi lễ. Bạn sẽ khó thực hiện điều đó một cách nghiêm túc, phải không? Trong trích dẫn này, điểm chính của anh ta là xác định thụt lề cho nhân linux là tám khoảng trắng, không hơn không kém, đó là điều anh ta cứng nhắc. Câu cuối cùng chỉ để nhấn mạnh điểm đó, không nói rằng bạn không được sử dụng nhiều mức độ thụt hơn - không có sự cứng nhắc ngụ ý.
cmaster

1
@cmaster Cảm ơn bối cảnh, ngay trên! Trả lời câu hỏi của bạn, tôi hầu như không coi trọng điều gì. ;)
Scant Roger

2
@cmaster và sau đó một người đọc phản hồi của mình đối với các yêu cầu kéo github và độ dài dòng của thông điệp cam kết. Ông là một trường hợp tổng thể.
Gusdor

3
Nghi thức đốt các hướng dẫn mã hóa GNU có thể không thực sự cần thiết, nhưng nó hoàn toàn theo thứ tự tại bất kỳ thời điểm nào.
dmckee

13

Linus có nói đùa không?

Tác phẩm được viết theo phong cách vui tươi cho thấy tác giả đã quen thuộc với cách thảo luận về phong cách mã hóa giữa các học viên nghiêm túc: Tất cả chúng ta đều có sở thích của mình, và chúng tôi bảo vệ họ một cách điên cuồng, nhưng ít nhất là một phần trong má. Chúng tôi hiểu rất rõ rằng phần lớn chỉ là vấn đề sở thích cá nhân. Ông nói, bằng rất nhiều từ, "Coding style is very personal, and I won't _force_ my views on anybody"- ít nhất là ngoài mã mà cá nhân ông duy trì. Nhưng sự nhất quán của phong cách trong một dự án nhất định là một ý tưởng rất tốt. Tôi muốn mã hóa theo kiểu tôi không thích hơn là xử lý nhiều kiểu trong một hàm nhất định.

Đây là một ví dụ về văn bản rõ ràng vui tươi:

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

Tinh nghịch (1).

Có thể cho rằng lời khuyên tốt là cố gắng tránh thụt ra khỏi tầm kiểm soát, mặc dù mức tối đa ba cấp có thể là cường điệu. Tôi sẽ không grep nguồn kernel và đếm chuỗi bốn ký tự tab, nhưng tôi cá là tiền bạn có thể tìm thấy ít nhất một cái mà Torvalds đã viết.

Mặt khác, nếu ai đó có thể viết kernel Linux mà không thường xuyên vượt quá ba cấp độ thụt lề, thì giới hạn ba cấp có thể là một bài tập đáng để thử trong một thời gian trong mã của riêng bạn, chỉ để xem nó đưa bạn đến đâu. Đây không giống như một sự thay đổi giới tính, bạn biết đấy. Đó không phải là một cam kết trọn đời.

Nếu bạn tình cờ gặp ai đó trên Internet, người nghĩ rằng anh ta hiểu lập trình tốt hơn Torvalds (2), thì bạn biết loại người nào thích nói chuyện lớn trên Internet.

Mặt khác, anh ta đã phạm tội hình sự về các tab tám không gian. Đó là sự say sưa của một người đàn ông nên được giữ trong sự kiềm chế và cho ăn qua một khe. Bốn không gian rõ ràng là chính xác.

(1) Nhưng lưu ý cách anh ta đặt sai một khoảng trắng trước các hình elip và hai khoảng trắng sau chúng và hai khoảng trắng sau khi dừng hoàn toàn. SAI, SAU, SAI. Và sau đó anh ta có túi mật trơ trẽn để thiến những kẻ dị giáo. Kẻ dị giáo là bạn, Torvalds! ĐÓ LÀ BẠN!

(2) Nếu bạn muốn nói về " hiểu cách thiết kế hệ thống kiểm soát nguồn ", có thể có một số chỗ để tranh luận.

Lưu ý: Kính gửi người dùng đã liên tục gửi bản chỉnh sửa tương tự: Định dạng trong tài liệu được trích dẫn được giữ chính xác như ý của tác giả. Đó là bởi vì đó là từ một bài tiểu luận về định dạng của văn bản có chiều rộng cố định, được viết bằng văn bản có chiều rộng cố định, bởi một người nào đó đã cho định dạng của văn bản có chiều rộng cố định một lượng suy nghĩ hợp lý. Định dạng là một phần có ý thức và có chủ ý trong ý định của tác giả và nó có liên quan đến chủ đề.

Ngoài ra, tôi đã đề cập lại định dạng đó trong văn bản của riêng tôi. Nếu bạn lấy ra định dạng trước, chú thích của tôi (1) sẽ trở nên vô nghĩa. Nếu định dạng trước bị loại bỏ, thì nên là văn bản trong chú thích của tôi (1) đề cập đến các cặp khoảng trắng sau khi dừng hoàn toàn ở cuối câu. Dù sao thì tôi cũng có thể thấy một lý do để xóa chú thích đó, vì nó ít gây cười hơn khi tôi viết nó. Nhưng để loại bỏ định dạng mà không xóa chú thích là không có ích.


3
Câu trả lời tuyệt vời. Một trong những trường hợp đáng được +2 ... (Lưu ý: Không có khoảng trắng sai .trong nhận xét này ;-))
cmaster

2
Đoạn giới thiệu của Linus mà bạn đã chỉ ra là rất quan trọng vì vậy cảm ơn bạn đã làm điều đó! Tôi nghĩ rằng câu đầu tiên cũng rất quan trọng đối với ngữ cảnh, cụ thể preferred coding stylecũng nhưbut this is what goes for anything that I have to be able to maintain
Chris Haas

9

Linus có phong cách nói chuyện rất thẳng thắn và khiếu hài hước khô khan, nhưng anh không đùa trong trường hợp này. Có những tình huống mà một thuật toán cần lồng nhau sâu hơn hai cấp độ, nhưng bạn có thể thực hiện điều này bằng các phương tiện khác ngoài việc thụt mã của bạn. Hướng dẫn kiểu nhân Linux thích mạnh mẽ các phương thức khác này, vì khó duy trì các vòng lặp lồng nhau sâu sắc, và đó là những gì Linus đang nói ở đây.

Đối với một số ví dụ về các phương thức thay thế, bạn có thể sử dụng đệ quy, tách các vòng lặp bên trong thành các hàm riêng của chúng hoặc tạo cấu trúc dữ liệu trung gian.

Làm tổ quá mức là một trong những trường hợp dễ viết hơn, nhưng khó đọc hơn. Đặt độ sâu tab lớn là cách viết của Linus khiến việc viết trở nên khó chịu hơn.


3

Có nhiều câu hỏi mà lời khuyên khác nhau đối với người hỏi câu hỏi so với người không hỏi. Nếu bạn hỏi "Tôi có bao giờ có các vòng lặp được lồng sâu hơn hai cấp độ không" thì đối với bạn, người hỏi câu hỏi đó, câu trả lời là KHÔNG. Nếu bạn hỏi, thì đừng làm. Nếu bạn có đủ kinh nghiệm mà bạn không cần phải hỏi, thì bạn sẽ biết câu trả lời đúng trong mỗi trường hợp là gì. Và đừng tranh luận nếu bạn không đồng ý với câu trả lời, vì câu trả lời không dành cho bạn.


1

Đây có vẻ là một trường hợp sách giáo khoa về cái đuôi vẫy con chó.

Nếu bạn có hiển thị 80 ký tự thì tất nhiên bạn sẽ thử và làm cho mã phù hợp nhất có thể ngay cả khi nó không tạo ra cấu trúc tốt nhất cho mã .

Giải quyết phần còn lại của điểm đầu của bạn trên:

Tôi nghĩ rằng đó là một thực tế không thể chấp nhận.

Tôi nghĩ rằng bạn đang đọc quá nhiều về điều này. Chống lại sự thôi thúc lấy mọi thứ bạn đọc làm phúc âm mà không hiểu đúng ngữ cảnh.

Anh ấy nói đùa à?

Khó xác định bối cảnh, nhưng xem điểm ban đầu của tôi ở trên.

Nó phụ thuộc vào ngôn ngữ hoặc ứng dụng?

Rất nhiều như vậy. Sử dụng bất kỳ ngôn ngữ máy tính lớn / tầm trung nào mà bạn có khả năng mã hóa trên thiết bị đầu cuối (hoặc trình giả lập thiết bị đầu cuối).

Có một số điều hoàn toàn cần ba hoặc nhiều cấp độ vòng lặp?

Vâng, nó rất phổ biến trong một số thuật toán vũ phu. Xem Bài toán 31 về Dự án Euler. Đây là một ví dụ kinh điển về một vấn đề có thể được giải quyết bằng vũ lực bằng cách sử dụng một số vòng lặp (chính xác là 8).


1
Có vẻ như Bài toán 31 không yêu cầu bruteforce và có thể được giải quyết bằng thuật toán lập trình động (chỉnh sửa: có nghĩa là cấu trúc mã của bạn không tốt nhất nếu bạn đang sử dụng thuật toán bruteforce). Ngoài ra, quan điểm của Linus là nếu mã của bạn yêu cầu nhiều mức thụt dòng, thì đó có thể không phải là cấu trúc tốt nhất cho mã.
Vincent Savard

2
@VincentSavard Không bao giờ nói nó cần vũ lực. Không đồng ý với điểm thứ 2 của bạn - đôi khi đó là cách tiếp cận rõ ràng và cô đọng nhất, chưa kể hiệu quả nhất trong một số trường hợp.
Robbie Dee

1
Với loại vấn đề đó, tôi thường không thụt vào các vòng. Tôi nghĩ rằng tôi đã có một trường hợp với 20 vòng lặp lồng nhau, hoàn toàn không đáng để viết và không có vết lõm để bạn có thể thấy các vòng lặp gần như giống hệt nhau.
gnasher729

1
@RobbieDee: Quan điểm của tôi là ví dụ của bạn về một vấn đề được giải quyết bằng nhiều vòng lặp là thuật toán của bạn không hiệu quả như một giải pháp lập trình động, không yêu cầu nhiều mức độ thụt lề. Do đó, như Linus đã nói, mức độ thụt đầu dòng của bạn có thể được loại bỏ bằng cách sử dụng một giải pháp tốt hơn. Bạn cũng hiểu nhầm điểm thứ hai của tôi vì tôi đồng ý với những gì bạn nói. Đôi khi , đó là giải pháp tốt nhất. Đôi khi không thường xuyên, và không có khả năng.
Vincent Savard

1
Trích dẫn của Linus khá rõ ràng nói rằng nếu một số mã yêu cầu một thứ gì đó như bruteforcing the Problem-31, thì dù sao bạn cũng bị lừa - nó sẽ không nhanh cũng không đơn giản và các thao tác kernel phải nhanh và đơn giản. Bao gồm bất kỳ thuật toán O (n ^ 4) nào trong kernel là rủi ro đáng kể về hiệu năng hoặc từ chối các vấn đề dịch vụ, do đó, trong bối cảnh này, khuyến nghị chỉ đơn giản là cảnh báo rằng đây là một dấu hiệu mã có thể không phù hợp về cơ bản và mong muốn trong Linux.
Peteris

0

Linus có nói đùa không?

Không, đó là những hướng dẫn chính thức.

Nó phụ thuộc vào ngôn ngữ hoặc ứng dụng?

Hướng dẫn mã hóa thường phụ thuộc vào ngôn ngữ và ứng dụng, tuy nhiên mã được lồng sâu luôn đánh thuế người đọc.

Vấn đề với mã lồng nhau là nói chung, nó làm tăng độ phức tạp theo chu kỳ: nghĩa là mã càng được lồng nhiều thì các đường dẫn thực thi tiềm năng càng tồn tại trong hàm. Một sự bùng nổ kết hợp của các đường dẫn thực thi tiềm năng gây khó khăn cho việc suy luận về mã, và do đó nên tránh nói chung.

Vậy tại sao 3? Một hướng dẫn mã hóa chủ quan là khó thực thi và không thể thực thi tự động. Thiết lập một hướng dẫn mã hóa khách quan ở mức độ thụt tối đa đòi hỏi phải đồng ý về một số: trong nhân Linux họ đã chọn 3.

Đó là tùy ý, và dường như đủ cho họ.

Có một số điều hoàn toàn cần ba hoặc nhiều cấp độ vòng lặp?

Thuật toán khôn ngoan, có lẽ, tuy nhiên, trong các ngôn ngữ đủ biểu cảm, bạn luôn có thể cấu trúc lại mã thành các phần nhỏ hơn (cho dù có chức năng hay đóng).

Bạn rõ ràng có thể viết mã bị xáo trộn với rất ít lồng nhau và rất nhiều hàm nhỏ gọi nhau mà không bao giờ đánh vần hợp đồng của họ ...

... tuy nhiên, các chức năng nhỏ có hợp đồng rõ ràng dễ kiểm toán hơn nhiều so với các chức năng lớn có hợp đồng rõ ràng nói chung.


2
Mặc dù đây có thể là hướng dẫn chính thức, nhưng việc tìm địa điểm trong mã hạt nhân nơi hướng dẫn không được thi hành là chuyện nhỏ.
MikeB

1
@MikeB: Tất cả các lý do khác để thực thi các hướng dẫn tự động ...
Matthieu M.

1
@MatthieuM. Bạn có chắc chắn bạn hiểu sự khác biệt giữa các hướng dẫn và các yêu cầu bắt buộc? Là một "quy tắc chung" (một hướng dẫn nếu bạn muốn), các hướng dẫn giống như các khuyến nghị và không được thi hành.
Brendan
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.