it-swarm-vi.com

Niềng răng xoăn nên xuất hiện trên dòng riêng của họ?

Có nên niềng răng xoăn trên đường dây của mình hay không? Bạn nghĩ gì về nó?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

hoặc nó nên

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

hoặc thậm chí

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Hãy xây dựng! Giải thích tại sao, chia sẻ kinh nghiệm, sao lưu nó với các sự kiện và tài liệu tham khảo.

284
Tamara Wijsman

Khi còn là sinh viên, tôi thường đặt các dấu ngoặc nhọn trên cùng một dòng, sao cho có ít dòng hơn và mã được in trên ít trang hơn. Nhìn vào một ký tự dấu ngoặc đơn được in là điều duy nhất trong một dòng là khó chịu. (môi trường, lãng phí giấy)

Nhưng khi mã hóa các ứng dụng lớn, cho phép một số dòng chỉ có niềng răng trong đó có giá cả phải chăng, xem xét cảm giác 'nhóm' mà nó mang lại.

Dù bạn chọn kiểu nào, hãy nhất quán để nó không trở thành chi phí cho bộ não của bạn để xử lý nhiều kiểu trong các đoạn mã liên quan. Trong các kịch bản khác nhau (như ở trên) tôi sẽ nói sử dụng các phong cách khác nhau là ổn, việc 'chuyển ngữ cảnh' ở mức cao sẽ dễ dàng hơn.

90
dbza

Bạn không bao giờ nên thực hiện phương pháp thứ 3.

Lướt qua niềng răng lần đầu tiên có thể giúp bạn tiết kiệm một vài lần nhấn phím, nhưng lập trình viên tiếp theo đi kèm, thêm điều gì đó vào mệnh đề khác của bạn mà không nhận thấy khối bị thiếu niềng răng sẽ gây ra rất nhiều đau đớn.

Viết mã của bạn cho người khác.

251
rhettg

Trong một thời gian dài, tôi lập luận rằng chúng có giá trị như nhau, hoặc rất gần bằng nha rằng mức tăng có thể bằng cách đưa ra lựa chọn đúng là rất xa, thấp hơn so với chi phí tranh luận về nó.

nhất quán là quan trọng, mặc dù. Vì vậy, tôi đã nói hãy lật một đồng xu và viết mã.

Tôi đã thấy các lập trình viên chống lại sự thay đổi như thế này trước đây. Hãy vượt qua nó! Tôi đã chuyển đổi nhiều lần trong sự nghiệp của mình. Tôi thậm chí sử dụng các kiểu khác nhau trong C # của mình hơn trong PowerShell.

Vài năm trước tôi đã làm việc trong một nhóm (~ 20 nhà phát triển) đã quyết định yêu cầu đầu vào, sau đó đưa ra quyết định và sau đó thực thi điều đó trên tất cả các cơ sở mã. Chúng tôi sẽ có 1 tuần để quyết định.

Rất nhiều tiếng rên rỉ & đảo mắt. Rất nhiều "Tôi thích cách của tôi, bởi vì nó tốt hơn" nhưng không có chất.

Khi chúng tôi đang nghiên cứu những điểm chính xác hơn của câu hỏi, có người đã hỏi làm thế nào để giải quyết vấn đề này theo kiểu giằng co:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Lưu ý rằng không rõ ràng ngay khi danh sách tham số kết thúc và phần thân bắt đầu. So với:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Chúng tôi đã đọc một số cách mọi người trên khắp thế giới đã giải quyết vấn đề này và tìm thấy mô hình thêm một dòng trống sau cú đúp mở:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Nếu bạn sẽ làm cho một phá vỡ thị giác, bạn cũng có thể làm điều đó với một cái nẹp. Sau đó, phá vỡ thị giác của bạn trở nên nhất quán, quá.

Chỉnh sửa: Hai lựa chọn thay thế cho giải pháp 'dòng trống thêm' khi sử dụng K & R:

1/Ấn định các đối số hàm khác với thân hàm

2/Đặt đối số đầu tiên trên cùng một dòng với tên hàm và căn chỉnh các đối số tiếp theo trên các dòng mới cho đối số đầu tiên đó

Ví dụ:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/ Chỉnh sửa

Tôi vẫn lập luận rằng tính nhất quán quan trọng hơn các cân nhắc khác, nhưng nếu chúng ta không có tiền lệ được thiết lập, thì brace-on-next-line là hướng đi.

206
Jay Bazuzi

Các quy tắc chính là:

  1. Thực hiện theo tiêu chuẩn mã hóa hiện có của dự án.
  2. Nếu không có tiêu chuẩn mã hóa và bạn đang chỉnh sửa một cơ sở mã hiện có thuộc sở hữu của người khác - hãy nhất quán với phong cách của mã hiện tại, bất kể bạn thích/không thích nó đến mức nào.
  3. Nếu bạn đang làm việc trong một dự án lĩnh vực xanh - thảo luận với các thành viên khác trong nhóm và đi đến thống nhất về một tiêu chuẩn mã hóa chính thức hoặc không chính thức.
  4. Nếu bạn đang làm việc trong một dự án trường xanh với tư cách là nhà phát triển duy nhất - hãy tạo ra suy nghĩ của riêng bạn, và sau đó là nhất quán một cách tàn nhẫn.

Ngay cả khi bạn không có ràng buộc bên ngoài nào, tốt nhất bạn nên tìm kiếm một hướng dẫn mã hóa hoặc tiêu chuẩn mã hóa hiện có (được sử dụng rộng rãi) và thử làm theo. Nếu bạn cuộn theo phong cách của riêng bạn, có một cơ hội tốt mà bạn sẽ phải hối tiếc trong một vài năm.

Cuối cùng, một kiểu được triển khai/thực hiện bằng cách sử dụng trình kiểm tra kiểu và trình định dạng mã hiện có sẽ tốt hơn một kiểu cần được "thi hành" theo cách thủ công.

103
Stephen C

Lợi ích của phương pháp đầu tiên là nó nhỏ gọn hơn theo chiều dọc, do đó bạn có thể phù hợp với nhiều mã hơn trên màn hình của mình và đó là lý do tại sao tôi thích nó hơn. Đối số duy nhất tôi nghe được có lợi cho phương pháp thứ hai là nó giúp việc ghép ngoặc mở và đóng dễ dàng hơn, nhưng hầu hết các IDE đều có một phím tắt cho điều đó và thực sự là một câu lệnh sai - thay vì ghép một dấu ngoặc mở với một đóng khung bạn có thể ghép một dấu ngoặc đóng với biểu thức "bắt đầu khối" (if, other, for, while) trên cùng một mức thụt đầu dòng, vì vậy thật dễ dàng để xác định vị trí bắt đầu của khối.

Tôi thấy không có lý do gì để lãng phí toàn bộ một dòng chỉ cho một dấu ngoặc khi trước đó cho/while/nếu cấu trúc đã trực quan chỉ ra sự bắt đầu của một khối.

Điều đó nói rằng, tôi tin rằng khung đóng phải nằm trong dòng riêng của nó bởi vì chúng ta cần một cái gì đó để chỉ ra sự kết thúc của một khối và cấu trúc thụt của nó theo cách có thể nhìn thấy.

72
EpsilonVector

Tôi thích

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

kết thúc

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

bởi vì dòng you.postAnswer(); dễ đọc và dễ nhìn hơn từ cái nhìn đầu tiên. Theo cách thứ hai, nó được hòa trộn với dòng phía trên nó (you.hasAnswer()) khiến mắt tôi phải tập trung hơn để đọc nó.

49
JD Isaacks

Tôi thích phương pháp đầu tiên. Niềng răng hoàn toàn không có giá trị riêng biệt.

Có điều là niềng răng không quan trọng. Họ chỉ rác tổng hợp, điều này hoàn toàn không cần thiết để hiểu mã được dùng cho mục đích gì và cách thức triển khai. Chúng chỉ là một sự tôn vinh đối với các ngôn ngữ giống như kiểu C cũ, nơi việc nhóm các nhà khai thác trực quan là không thể do không gian màn hình thấp có sẵn.

Có những ngôn ngữ (Python, Haskell, Ruby) vẫn ổn mà không cần niềng răng. Điều này chỉ xác nhận rằng niềng răng là rác, và không nên xứng đáng có một dòng cho chúng bất cứ khi nào có thể:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}
39
P Shved

Sử dụng Python và bỏ qua hoàn toàn đối số.

37
Mark Ransom

Vị trí của niềng răng nên

dữ liệu meta

có thể định cấu hình trong IDE bởi lập trình viên. Bằng cách đó, các dấu ngoặc nhọn trong tất cả các mã, bất kể tác giả, trông giống nhau.

28
Jonathan

Tôi thích cái đầu tiên vì tôi khó nhìn thấy lỗi hơn trong ví dụ này.

if (value > maximum);
{
    dosomething();
}

hơn trong ví dụ này

if (value > maximum); {
    dosomething();
}

Các ; { chỉ có vẻ sai đối với tôi hơn là một dòng kết thúc bằng ; vì vậy tôi có nhiều khả năng nhận thấy nó.

19
bmb

Nó phụ thuộc.

Nếu tôi đang mã hóa bằng Javascript hoặc jQuery, tôi sử dụng mẫu đầu tiên:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Nhưng nếu tôi viết mã bằng C #, tôi sử dụng mẫu thứ hai, vì đó là cách chính tắc để làm điều đó trong C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Lưu ý rằng ví dụ của bạn có thể được viết

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

trong C #.

19
Robert Harvey

Tôi thích một biến thể nhỏ của 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Tại sao?

  • Tôi nghĩ luôn luôn đặt niềng răng trên dòng riêng của họ làm giảm khả năng đọc. Tôi chỉ có thể chứa một số mã nguồn nhất định trên màn hình của mình. Kiểu khung 2) làm cho các thuật toán nặng nề với rất nhiều vòng lặp lồng nhau và các điều kiện dài một cách đau đớn.

  • Tuy nhiên, tôi muốn else bắt đầu trên một dòng mới vì ifelse thuộc về nhau, trực quan. Nếu có một dấu ngoặc ở phía trước else, thì việc phát hiện ra những gì thuộc về cái gì sẽ khó khăn hơn nhiều.

  • 3) không đủ tiêu chuẩn. Chúng ta đều biết những điều tồi tệ có thể xảy ra nếu bạn bỏ dấu ngoặc và quên nó đi.

15
Alexander Gessler

Tôi đã đọc ở đâu đó rằng các tác giả của một số cuốn sách muốn mã của họ được định dạng như thế này:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Nhưng những hạn chế về không gian từ nhà xuất bản của họ có nghĩa là họ phải sử dụng điều này:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Bây giờ tôi không biết liệu điều đó có đúng không (vì tôi không thể tìm thấy nó nữa), nhưng phong cách thứ hai rất phổ biến trong sách.

Ở cấp độ cá nhân, tôi thích các dấu ngoặc trên một dòng riêng biệt như:

a) họ chỉ ra một phạm vi mới
[.__.] b) sẽ dễ dàng phát hiện hơn khi bạn gặp sự cố không khớp (mặc dù đây không phải là vấn đề trong IDE làm nổi bật lỗi cho bạn).

10
ChrisF

À, Một kiểu chân thực .

Nó có mọi thứ cần thiết cho Holy Way - thậm chí là một nhà tiên tri (Richard "cách của tôi hoặc đường cao tốc" Stallman).

Anh chàng đã sai rất nhiều về rất nhiều thứ, nhưng GNU là tại chỗ khi nói đến niềng răng.


[Cập nhật] Tôi đã thấy ánh sáng, và bây giờ tôn thờ Allman

10

Câu trả lời đơn giản: cái gì dễ gỡ lỗi hơn?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

Trong trường hợp nào bạn đã chẩn đoán vấn đề đầu tiên?

Tôi không quan tâm nhiều đến sở thích cá nhân (có nhiều phong cách khác, bao gồm cả người da trắng và cộng sự) và tôi không quan tâm nhiều ... miễn là điều đó không cản trở khả năng đọc mã của tôi và gỡ lỗi nó.

Đối với đối số "không gian lãng phí", tôi không mua nó: Tôi có xu hướng thêm các dòng trống giữa các nhóm logic để làm cho chương trình rõ ràng hơn ...

9
Matthieu M.

Ví dụ thứ hai, tôi rất lớn về khả năng đọc. Tôi không thể đứng nhìn nếu chặn bất kỳ cách nào khác = (

9
Bryan Harrington

Không phải ai cũng sẽ chú ý, nhưng đây là lý do tại sao niềng răng thuộc về cùng dòng là điều kiện (ngoại trừ các điều kiện rất dài, nhưng đó là trường hợp Edge):

Trong C, đây là một cấu trúc hợp lệ:

[.__.] while (đúng); [.__.] {[.__.] char c; [.__.] getchar (); // Đợi đầu vào [.__.]} [.__.]

Nhanh chóng! Mã này làm gì? Nếu bạn trả lời "vòng lặp vô hạn yêu cầu đầu vào", bạn đã sai! Nó thậm chí không nhận được đầu vào. Nó bị bắt tại while(true). Lưu ý rằng dấu chấm phẩy ở cuối. Mô hình này thực sự phổ biến hơn mà có vẻ như nó phải như vậy; C yêu cầu bạn khai báo các biến của bạn khi bắt đầu một khối, đó là lý do tại sao một biến mới được bắt đầu.

Một dòng mã là một suy nghĩ. Niềng răng là một phần của ý nghĩ chứa điều kiện hoặc vòng lặp. Do đó, chúng thuộc về cùng dòng.

8
Christian Mann

Tôi thích phương pháp đầu tiên. Nó có vẻ gọn gàng hơn IMO, và nó nhỏ gọn hơn, mà tôi thích.

EDIT: Ah, một phần ba. Tôi thích cái đó tốt nhất khi có thể, vì nó thậm chí còn nhỏ hơn/gọn gàng hơn.

5
Ullallulloo

Bạn có thể viết nó:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Để trả lời câu hỏi; Tôi đã từng thích sử dụng dấu ngoặc nhọn trên dòng riêng của họ, nhưng, để tránh phải suy nghĩ về các lỗi từ chèn dấu chấm phẩy tự động trong trình duyệt, tôi bắt đầu sử dụng kiểu Ai Cập cho javascript. Và khi mã hóa Java trong Eclipse, tôi không có hứng thú với việc chiến đấu (hoặc định cấu hình) kiểu giằng mặc định, vì vậy tôi cũng đã đi với Ai Cập trong trường hợp đó. Bây giờ tôi cũng ổn với cả hai.

5
FeatureCreep

Gần như tất cả các câu trả lời ở đây đều nói một số biến thể về "Dù bạn làm gì, hãy gắn bó với một hoặc hai".

Vì vậy, tôi nghĩ về nó một lúc và phải thừa nhận rằng tôi không thấy nó quan trọng. Bất cứ ai có thể thành thật nói với tôi rằng những điều sau đây là khó theo dõi?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Tôi không chắc chắn về bất cứ ai khác ... nhưng tôi hoàn toàn không có vấn đề gì về mặt tinh thần chuyển đổi qua lại giữa các phong cách. Tôi đã mất vài phút để tìm ra mã đã làm gì, nhưng đó là kết quả của việc tôi chỉ gõ ngẫu nhiên cú pháp giống như C. :)

Theo ý kiến ​​không hề khiêm tốn của tôi, việc niềng răng mở gần như hoàn toàn không liên quan đến khả năng đọc mã. Có một vài trường hợp góc được liệt kê ở trên trong đó một kiểu này hoặc kiểu kia tạo ra sự khác biệt, nhưng đối với hầu hết các phần, việc sử dụng hợp lý các dòng trống sẽ làm sạch nó.

FWIW, các kiểu mã hóa của chúng tôi tại nơi làm việc sử dụng mẫu 1 có cấu trúc hơn một chút và mẫu được sửa đổi 3. (C++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Tôi tò mò liệu những người mạnh mẽ thích mẫu 2 sẽ tìm thấy phiên bản của mẫu 1 này tốt hơn, chỉ vì dòng trống mang lại sự tách biệt thị giác mạnh mẽ hơn.

4
jkerian

Tôi ngạc nhiên khi điều này chưa được nêu ra. Tôi thích cách tiếp cận thứ hai vì nó cho phép bạn chọn khối dễ dàng hơn.

Khi niềng răng bắt đầu và kết thúc trên cùng một cột và trên dòng riêng của chúng, Bạn có thể chọn từ lề hoặc bằng con trỏ trên cột 0. Điều này thường tương đương với một khu vực hào phóng hơn với lựa chọn chuột hoặc ít lần nhấn phím hơn với lựa chọn bàn phím.

Ban đầu tôi làm việc với niềng răng trên cùng một dòng với điều kiện, nhưng khi tôi chuyển đổi, tôi thấy nó tăng tốc độ mà tôi làm việc. Tất nhiên, đó không phải là ngày và đêm, nhưng điều gì đó sẽ khiến bạn chậm lại khi làm việc với niềng răng bên cạnh điều kiện của bạn.

4
Tim O'Neil

Sở thích cá nhân của tôi là phương pháp đầu tiên, có lẽ vì đó là cách đầu tiên tôi học PHP.

Đối với các câu lệnh if một dòng, tôi sẽ sử dụng

if (you.hasAnswer()) you.postAnswer();

Nếu đó không phải là you.postAnswer(); mà là một cái gì đó dài hơn rất nhiều, chẳng hạn như you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); Có lẽ tôi sẽ trở lại loại đầu tiên:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Tôi sẽ không bao giờ sử dụng ngắt dòng và tôi sẽ không bao giờ sử dụng phương thức này nếu có câu lệnh else.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

là một khả năng lý thuyết, nhưng không phải là một khả năng tôi từng sử dụng. Điều này sẽ phải được biến thành

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}
2
TRiG

Cá nhân tôi thích cách thứ hai.

Tuy nhiên, theo cách tôi sẽ chứng minh là theo ý kiến ​​của tôi tốt nhất bởi vì nó mang lại sự bảo mật công việc lớn nhất! Một sinh viên từ trường đại học của tôi đã nhờ tôi giúp đỡ về bài tập về nhà và đây là cách mã của anh ấy trông như thế nào. Toàn bộ chương trình trông giống như một khối duy nhất. Điều thú vị là 95% lỗi trong chương trình mà anh ấy tạo ra đến từ niềng răng không khớp. 5% còn lại là hiển nhiên khi niềng răng được khớp.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);
2
AndrejaKo

Họ không nên; phương pháp đầu tiên cho tôi.

Khi tôi nhìn vào cái thứ hai, vì các dòng không được sử dụng (những dòng chỉ có dấu ngoặc trên nó, ngoại trừ dấu ngoặc cuối cùng), nó có cảm giác như nó phá vỡ tính liên tục của mã. Tôi không thể đọc nó nhanh vì tôi cần đặc biệt chú ý đến các dòng trống, điều này thường có nghĩa là sự phân tách trong mục đích mã hoặc một cái gì đó như thế này, nhưng trong trường hợp "dòng này thuộc về một dấu ngoặc nhọn" (chỉ lặp lại ý nghĩa của vết lõm).

Dù sao, giống như khi bạn viết văn bản ... thêm một vết lõm ở đầu đoạn văn là không cần thiết nếu có một dòng trống trước nó (dấu hiệu kép của thay đổi đoạn văn), không cần phải lãng phí dòng cho dấu ngoặc khi chúng ta thụt lề đúng cách.

Thêm vào đó, như đã nêu, nó cho phép điều chỉnh nhiều mã hơn trong màn hình, điều này ngược lại sẽ hơi phản tác dụng.

2
Joanis

Nó phụ thuộc vào nền tảng/ngôn ngữ/quy ước

Trong Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

Trong C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

Trong C:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Tôi ghét khi Java kẻ sử dụng phong cách của họ trong mã C # và ngược lại.

2
OscarRyz

Tôi sử dụng phương pháp đầu tiên đơn giản vì nó nhỏ gọn hơn và cho phép nhiều mã hơn trên màn hình. Bản thân tôi chưa bao giờ gặp vấn đề với việc ghép cặp niềng răng (tôi luôn viết chúng ra, cùng với câu lệnh if trước khi thêm điều kiện và hầu hết các môi trường cho phép bạn nhảy đến niềng răng phù hợp).

Nếu bạn đã cần ghép nối trực quan với niềng răng, thì tôi thích phương pháp thứ hai hơn. Tuy nhiên, điều đó cho phép ít mã hơn cùng một lúc đòi hỏi bạn phải cuộn nhiều hơn. Và điều đó, đối với tôi ít nhất, có tác động lớn hơn đến việc đọc mã hơn là có niềng răng được sắp xếp gọn gàng. Tôi ghét di chuyển. Sau đó, một lần nữa, nếu bạn cần cuộn qua một câu lệnh if, thì rất có thể nó quá lớn và cần tái cấu trúc.

Nhưng; điều quan trọng nhất của tất cả là sự nhất quán. Sử dụng cái này hay cái kia - không bao giờ cả hai!

1
gablin

Tất cả những gì tôi có thể nói là nếu bạn là người hâm mộ phương pháp # 3, bạn sẽ bị bắt bớ bởi mọi IDE công cụ định dạng mã trên trái đất.

1
Phil Cohen

Có một tùy chọn thứ 4 giữ cho niềng răng thẳng hàng, nhưng không lãng phí không gian:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Vấn đề duy nhất là hầu hết các bộ lọc tự động của IDE bị nghẹt thở vì điều này.

0
AShelly

Khi tôi lần đầu tiên học lập trình ở tuổi 12, tôi đã đặt niềng răng ở dòng tiếp theo bởi vì các hướng dẫn mã hóa của Microsoft là như thế. Tôi cũng thụt lề với TABS 4 không gian lúc đó.

Sau một vài năm, tôi đã học được Java và JavaScript và thấy nhiều mã niềng răng trên cùng một dòng, vì vậy tôi đã thay đổi. Tôi cũng bắt đầu thụt lề với SPACES 2 không gian.

0
Ming-Tang