2011-01-09 22 views
10

Ví dụ: Thread::Thread:Tôi nên thụt lề như thế nào để không làm gì khởi tạo danh sách khởi tạo?

class Thread 
{ 
    Process * parent_; 
    unsigned __int32 id_; 
    void * entryPoint_; 
public: 
    Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
     parent_(parent), 
     id_(id), 
     entryPoint_(entryPoint) 
    { 
    } 
    unsigned __int32 GetId() const 
    { 
     return id_; 
    } 
    void * GetEntryPointAddress() const 
    { 
     return entryPoint_; 
    } 
}; 

tôi dường như không thể tìm ra một cách để thụt điều để nó không giống kỳ lạ ... nhưng đây là một mô hình phổ biến. Cách phổ biến của indenting này là gì?

+0

Như tôi đã trả lời các câu hỏi như thế này trước đây: Miễn là bạn nhất quán, nó thực sự không quan trọng. :) (Điều đó nói rằng, tôi tò mò tại sao bạn nghĩ rằng nó trông lạ. Nó trông hoàn toàn tốt với tôi. :) – greyfade

+0

đặt nó tất cả trong một dòng và không nghĩ về nó! : D – ybungalobill

+1

@greyfade: Một phần của việc nhất quán đang làm những gì người khác làm. Tôi chưa từng thấy ai bày tỏ ý kiến ​​về điều này, nên tôi hỏi. Không biết chính xác lý do tại sao - chỉ làm cho tôi rìa vì một lý do nào đó. @ybungalobill: Điều đó làm cho việc hợp nhất mọi thứ trong kiểm soát nguồn khó khăn. –

Trả lời

17

Tôi luôn đặt các khối trống trên một dòng - tức là { } (chú ý khoảng trống!).

Hơn nữa, tôi thường đặt dấu hai chấm và dấu phẩy trước thành viên danh sách khởi tạo thay vì sau - điều này làm cho việc thêm thành viên sau này trở nên dễ dàng hơn.

Thread(Process * parent, unsigned __int32 id, void * entryPoint) 
    : parent_(parent) 
    , id_(id) 
    , entryPoint_(entryPoint) 
{ } 
+0

BTW (mặc dù tôi không sử dụng kiểu này) kiểu này có thể là tốt vì đó là chỉ có một MS Visual Studio sẽ không gây rối với định dạng tự động của nó. – anatolyg

+2

Đôi khi khi có vẻ như tôi nên có mã Tôi thêm một bình luận/* Cố ý Empty */(nhưng chỉ khi nó cần phải được giải thích). –

+0

@Martin: Bạn có thêm một cái ở đây không? –

3

Đây là cách tôi làm điều đó:

Thread(Process * parent, unsigned __int32 id, void * entryPoint) 
    :parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
{} 

Nhưng theo cách của bạn trông không xa lạ với tôi.

2

Đây là cách tôi làm điều đó

public: 
    Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
    parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
    { } 

Google phong cách (ít nhất protobuf), sẽ là:

public: 
Thread(Process * parent, 
     unsigned __int32 id, 
     void * entryPoint) 
    : parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) { } 
2

Đây là cách tôi làm điều đó, và tại sao tôi không thấy bất cứ điều gì sai với mẫu của bạn:

Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
     parent_(parent), 
     id_(id), 
     entryPoint_(entryPoint) { } 

Là theo như tôi quan tâm, hãy thực hiện theo cách của bạn: Miễn là bạn tự đồng nhất và nhất quán với dự án bạn đang làm việc, nó không phải là vấn đề phong cách thụt lề của bạn là gì.

0

Tôi khuyên bạn nên đặt nhận xét vào phần thân hàm dựng sẵn trống, chỉ để mọi người đọc mã biết bạn dự định để trống. Bằng cách đó họ có thể chắc chắn rằng nó không phải là một trường hợp của bạn đã quên để chèn mã ở đó.

Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
    parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
{ 
    // empty 
} 
+1

bạn biết không, tôi thực sự không thích điều này bởi vì nó sẽ làm cho ai đó sợ hãi khi đặt mã ở đây sau. Nhưng nếu cần thiết, người bảo trì không nên bị ép buộc/bị trói buộc vào suy nghĩ không làm điều đó bằng một bình luận đáng sợ. –

+0

"trống" là một bình luận đáng sợ, thực sự? Tôi đoán một người có thể rõ ràng hơn, ví dụ: "// Tôi cố tình không đặt bất kỳ mã nào ở đây, nhưng bạn cứ tiếp tục nếu bạn nghĩ đó là điều đúng đắn để làm" nhưng tôi nghĩ rằng có thể hơi quá mức. Bình luận sẽ ít đáng sợ đối với một người bảo trì hơn là buộc anh ta phải cố gắng đoán ý định của tác giả ban đầu là gì, do không có bất kỳ manh mối nào về lý do tại sao thân phương thức trống. –

Các vấn đề liên quan