Tôi nên tổ chức mã nguồn Python như thế nào? [đóng cửa]


99

Tôi đang bắt đầu với Python (đã đến lúc tôi thử nghiệm) và tôi đang tìm kiếm một số phương pháp hay nhất.

Dự án đầu tiên của tôi là một hàng đợi chạy thử nghiệm dòng lệnh trong nhiều luồng. Tôi đang bắt đầu nhận được một main.pytập tin rất dài và tôi muốn chia nhỏ nó ra. Nói chung, tôi đang tìm kiếm: Làm cách nào để các lập trình viên python tổ chức nhiều tệp nguồn? Có cấu trúc cụ thể nào phù hợp với bạn không?

Các câu hỏi cụ thể của tôi bao gồm:

  1. Mỗi lớp có nên nằm trong một tệp riêng biệt không?
  2. Tôi nên tổ chức các bài kiểm tra đơn vị liên quan đến mã nguồn như thế nào?
  3. Tôi nên đặt các nhận xét doc, đặc biệt là những nhận xét cho hoạt động dòng lệnh ở đâu?
  4. Nếu tôi sử dụng nhiều thư mục, làm cách nào để nhập các lớp giữa chúng?

Tôi có thể rút ra một số kết luận của riêng mình ở đây bằng cách thử và sai, nhưng tôi muốn bắt đầu từ một cái gì đó tốt .


4
Điều này sẽ giải thích một số điều về tổ chức mã của bạn docs.python.org/tutorial/modules.html
Nikola Smiljanić

2
Đây là một số thông tin hữu ích hơn từ tài liệu python. <br> docs.python.org/3/tutorial/modules.html#packages
rda3mon

11
Câu hỏi này nhằm tìm kiếm một quy ước được chấp nhận rộng rãi đặc biệt trong cộng đồng Python. Câu trả lời không phải là vấn đề quan điểm, mặc dù giống như hầu hết các câu trả lời, nó có thể thay đổi theo thời gian. Tôi đề nghị mở lại câu trả lời hoặc ít nhất là câu trả lời ban đầu không bị xóa.
Andres Jaan Tack,

Câu trả lời:


32

Các bài viết Eric chỉ để là tuyệt vời vì nó bao gồm chi tiết về tổ chức lớn đang căn cứ Python.

Nếu bạn đã đến đây từ Google và đang cố gắng tìm cách chia một tệp nguồn lớn thành nhiều tệp, dễ quản lý hơn, tôi sẽ tóm tắt quá trình một cách ngắn gọn.

Giả sử bạn hiện có mọi thứ trong một tệp có tên main.py:

  • Tạo một tệp nguồn khác trong cùng một thư mục ( utils.pyví dụ này gọi là của chúng tôi )
  • Di chuyển bất kỳ lớp, hàm, câu lệnh, v.v. nào bạn cần main.pyvàoutils.py
  • Trong main.pythêm một dòng duy nhất ở đầu trang:import utils

Về mặt khái niệm, điều này làm là tạo một mô-đun mới được gọi utilstrong một tệp nguồn khác. Sau đó, bạn có thể nhập nó vào bất cứ nơi nào cần.


Bạn có tình cờ nhớ bài báo mà Eric đã chỉ tới không? Tôi dường như không thể tìm thấy một Eric về câu hỏi này / câu trả lời
Daniel Rucci

7
@DanR, vâng, đây là bài báo . Vì lý do nào đó, một người kiểm duyệt đã xóa câu trả lời của mình, mặc dù nó có 56 lượt ủng hộ.
Drew Noakes

1
@DrewNoakes: Tôi nghĩ nó đã bị xóa vì chỉ là câu trả lời liên kết; giá như anh ấy đã tóm tắt những điểm chính của bài báo.
smci

1
Thật không may, bài viết hiện là một liên kết chết :-(. Phiên bản lưu trữ mới nhất ở đây: web.archive.org/web/20190714164001/http://…
Igor Brejc

7

Cách bạn nên tổ chức mã và các bài kiểm tra của mình giống hệt như cách bạn làm đối với bất kỳ ngôn ngữ OO nào.

Câu trả lời từ cách tôi làm điều đó. Nó có thể không đúng nhưng phù hợp với tôi

  1. Phụ thuộc vào cách phân chia chức năng của bạn. Đối với ứng dụng python chính của tôi, tôi có 1 tệp với các lớp cho các điểm nhập và sau đó là các gói chức năng khác nhau
  2. Tôi sử dụng PyDev cho nhật thực và sắp xếp nó giống như tôi làm cho Java.
>  Workspace
>     |
>     |-Src
>     |   |-Package1
>     |   |-Package2
>     |   |-main.py
>     |-Test
>         |-TestPackage1
>         |-TestPackage2
  1. Sử dụng DocString ở mọi nơi để theo dõi mọi thứ
  2. Sau khi đảm bảo rằng các __init__.pytệp có liên quan nằm trong các thư mục. nó chỉ là một trường hợp đơn giản củafrom module import class

5
Tuy nhiên, có một lưu ý: java có mối quan hệ độc tài với các gói, tệp và lớp. Đôi khi tôi kết thúc với nhiều tệp nguồn hơn tôi thực sự muốn. Quy ước của một số tổ chức - ví dụ - tránh (lồng nhau) các lớp bên trong hoặc các lớp "trợ giúp" thấp hơn trong tệp - làm cho điều này trở nên tồi tệ hơn, vượt quá yêu cầu của trình biên dịch. Giữ nó có trật tự và hệ thống phân cấp là hữu ích, nhưng hãy cố gắng tránh làm việc.
Roboprog
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.