Làm cách nào để mã của tôi sẵn sàng cho OpenSource và đưa nó vào GitHub?


9

Trong vài tuần nữa, dự án của tôi sẽ hoàn thành và tôi muốn bắt đầu chuẩn bị mã của mình cho người khác sử dụng.

Tôi sẽ đăng tất cả mọi thứ lên GitHub để mọi người có thể tinh chỉnh nó và hy vọng làm cho nó tốt hơn.

Tôi đoán những gì tôi đang hỏi là, cách tốt nhất để đảm bảo mã của tôi được ghi chép đầy đủ và diễn đạt đúng cho người khác sử dụng là gì?

Tôi biết bạn nên luôn nhận xét mọi thứ và tôi sẽ đưa vào tính năng @params cho mọi phương thức, nhưng có bất kỳ mẹo nào khác nói chung không?


Câu trả lời:


12
  • Đảm bảo có tệp README.txt trong thư mục gốc của kho lưu trữ hướng dẫn mọi người hướng dẫn cách xây dựng tệp. Các hướng dẫn có thể nằm trong tệp đó hoặc chúng có thể nằm trong một tệp hoặc trang wiki riêng.
  • Lý tưởng nhất là làm cho nó để bạn hoàn toàn có thể xây dựng và kiểm tra mã bằng một lệnh duy nhất. Đừng yêu cầu một loạt các bước thủ công.
  • Hãy chắc chắn rằng bạn có các bài kiểm tra cho mã. Điều này cung cấp một nơi thuận tiện cho các nhà phát triển khác để xem cách sử dụng mã của bạn, cộng với nó cung cấp một mạng lưới an toàn cho những người sửa đổi mã của bạn. Biết tôi có thể chỉnh sửa mã của bạn và sau đó chạy một bộ để xem nếu tôi phá vỡ một cái gì đó là vô giá.
  • Thực hiện theo các tiêu chuẩn mã hóa phổ biến hoặc xuất bản những cái bạn sử dụng.
  • Nếu mã của bạn sử dụng OO, hãy đảm bảo ít nhất tất cả các phương thức và thuộc tính công khai có đủ tài liệu
  • Hãy chắc chắn rằng mã của bạn sử dụng giấy phép nào. Thông thường, điều này có nghĩa là bao gồm tệp LICENSE.txt hoặc tuân theo bất kỳ cơ chế nào mà giấy phép cụ thể của bạn yêu cầu. Ngoài ra, hãy lựa chọn có ý thức về giấy phép. Đừng chỉ sử dụng GPL vì đó là tất cả những gì bạn biết. Tương tự, không chỉ sử dụng BSD hoặc MIT hoặc Apache nếu đó là tất cả những gì bạn quen thuộc ... dành một giờ để nghiên cứu những điều đó để bạn ít nhất hiểu được sự khác biệt cơ bản giữa giấy phép GPL và không GPL.
  • Xóa tất cả thông tin nhạy cảm khỏi mã, chẳng hạn như tên người dùng được mã hóa cứng, mật khẩu, địa chỉ email, địa chỉ IP, khóa API, v.v. (nhờ Hakan Deryal cho đề xuất)

Lời khuyên tốt. Ngoài ra một điều khác để thêm: Xóa thông tin cá nhân như mật khẩu / khóa api nếu có.
Hakan Deryal

Nếu bạn có bất kỳ thông tin nhạy cảm nào trong mã, bạn có thể cần phải cẩn thận để xóa thông tin đó khỏi các cam kết trong quá khứ (nếu bạn đã bắt đầu sử dụng kiểm soát phiên bản). Một cách dễ dàng để làm điều đó là tạo một kho lưu trữ hoàn toàn mới cho phiên bản công khai, nhưng đó có thể không phải là cách tiếp cận tốt nhất.
yakiv

3

Tài liệu trong tệp nguồn luôn tốt, nhưng bạn nên xuất bản thêm tài liệu trên một trang web. Giải thích mục tiêu của nó, cách thức hoạt động, kế hoạch tương lai của bạn, cố gắng đóng góp dễ dàng (nếu không ... sẽ không có ai giúp bạn) và đặt một số hướng dẫn.

Cố gắng làm việc trên một dự án với tài liệu mã nguồn chỉ luôn luôn bực bội.


1

Tôi đoán những gì tôi đang hỏi là, cách tốt nhất để đảm bảo mã của tôi được ghi chép đầy đủ và diễn đạt đúng cho người khác sử dụng là gì?

Là nguồn mở, các bình luận quan trọng nhất của tất cả là bình luận về bản quyền và thỏa thuận cấp phép. Thay vì một bình luận dài ở đầu mỗi tệp, bạn có thể muốn sử dụng một bình luận ngắn và ngọt, chỉ định ngắn gọn bản quyền và giới thiệu người đọc đến License.txt trong thư mục gốc.

Tôi biết bạn nên luôn nhận xét mọi thứ và tôi sẽ đưa vào tính năng @params cho mọi phương thức, nhưng có bất kỳ mẹo nào khác nói chung không?

Nhận xét mọi thứ? Không. Nhận xét rằng mã thực sự cần bình luận. Bình luận tiết kiệm. Là người dùng tiềm năng của một đoạn mã, hai phiên bản sau của định nghĩa lớp bạn muốn xem là gì?

Phiên bản A:

class Foo {
private:
   SomeType some_name; //!< State machine state

public:
   ...

   /**
    * Get the some_name data member.
    * @return Value of the some_name data member.
    */
   SomeType get_some_name () const { return some_name; }

   ...
};

Phiên bản B:

/**
 * A big long comment that describes the class. This class header comment is very
 * important, but also is the most overlooked. The class is not self-documenting.
 * Why is that class here? Your comments inside the class will say what individual parts
 * do, but not what the class as a whole does. For a class, the whole is, or should be,
 * greater than the parts. Do not forget to write this very important comment.
 */
class Foo {
private:

   /**
    * A big long comment that describes the variable. Just because the variable is
    * private doesn't mean you don't have to describe it. You might have getters and
    * setters for the variable, for example.
    */
   SomeType some_name;

public:
   ...

   // Getters and setters
   ...

   // Getter for some_name. Note that there is no setter.
   SomeType get_some_name () const { return some_name; }

   ...

};

Trong phiên bản A tôi đã ghi lại tất cả mọi thứ - ngoại trừ chính lớp đó. Một lớp học nói chung không phải là tài liệu tự. Các ý kiến ​​có trong phiên bản A hoàn toàn vô dụng, hoặc thậm chí tệ hơn vô dụng. Đó là vấn đề chính với thái độ "bình luận mọi thứ". Nhận xét ngắn gọn đó về thành viên dữ liệu riêng tư không liên lạc gì và các bình luận doxygen trên getter có giá trị âm. Các getter get_some_name()không thực sự cần một bình luận. Những gì nó làm và những gì nó trả lại là rõ ràng từ mã. Rằng không có setter - bạn phải suy luận rằng vì nó không có ở đó.

Trong phiên bản B tôi đã ghi lại rằng cần bình luận. Các getter không có một bình luận doxygen, nhưng nó có một bình luận đề cập rằng không có setter.

Làm cho ý kiến ​​của bạn được tính và hãy cẩn thận rằng các bình luận thường không được duy trì để phản ánh các thay đổi đối với mã.

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.