Nơi nào bạn đi để đọc các ví dụ tốt về mã nguồn? [đóng cửa]


53

Tôi đã nghe một vài người nói rằng một trong những cách tốt nhất để cải thiện khả năng mã hóa của bạn là đọc mã của người khác và hiểu nó. Câu hỏi của tôi, là một lập trình viên tương đối mới, tôi sẽ đi đâu để tìm các ví dụ mã nguồn tốt không quá xa đầu?


Điều này đã được hỏi trên StackOverflow: stackoverflow.com/questions/3083525/
triệt

3
Tôi chỉ nhìn lại mã cũ của tôi.
Paul

Paul, điều đó sẽ không giúp OP phải không? Rõ ràng là họ không có mã tốt đã được viết trong quá khứ. sheesh.
Junky

2
@junky hy vọng họ có chút hài hước :)
Konrad Morawski

Đây là câu hỏi tôi sẽ hỏi nhưng may mắn là tôi đã tìm thấy nó. Tôi nghĩ đây chỉ là vấn đề của tôi mà tôi không biết tìm mã ở đâu
Dhananjay

Câu trả lời:


30

Bạn có thể duyệt các dự án nguồn mở trên các trang lưu trữ như GitHub , Codeplex , Google Code hoặc BitBucket . Bạn sẽ tìm thấy các dự án có mức độ phức tạp khác nhau, vì vậy ban đầu bạn sẽ có thể tìm thấy thứ gì đó vừa khiến bạn quan tâm vừa không vượt quá đầu bạn.

Một lựa chọn khác là các bài đăng trên blog Mã nguồn hàng tuần của Scott Hanselman .

Tôi khuyên bạn nên bắt đầu với một dự án đang hoạt động, đã được thiết lập để giảm tỷ lệ bắt đầu đọc mã chưa được sử dụng và xem xét kỹ lưỡng. Lý tưởng nhất là tìm thứ gì đó khiến bạn quan tâm và bạn có thể sử dụng. Sử dụng ứng dụng sẽ giúp bạn hiểu mã nguồn. Một lợi ích khác của việc chọn một dự án nguồn mở là bạn có thể đóng góp một số bản sửa lỗi hoặc các tính năng, điều này sẽ giúp việc đọc qua mã trở nên thú vị hơn.

Nhìn chằm chằm vào một loạt mã của người khác có thể đáng sợ, vì vậy hãy bắt đầu với mainchức năng (hoặc tương đương) và thực hiện theo cách của bạn từ đó.


3
-1: người mới bắt đầu không thể phân biệt giữa mã tốt và mã xấu, vì vậy các dự án 'duyệt' sẽ không có ích. Bạn đã bảo vệ điều này bằng cách đề xuất các dự án 'đã thành lập', nhưng tôi đã thấy mã khủng khiếp trong các dự án mà tất cả chúng ta đã nghe nói đến. Tôi không có một câu trả lời tốt hơn, mặc dù. Đây thực sự là một câu hỏi khó, cần một câu trả lời phù hợp với cấp độ kỹ năng, sở thích của từng cá nhân và được lọc qua kiến ​​thức của người cố vấn.
Khủng hoảng

1
@Cris Tôi không đồng ý, nhưng tôi sẽ lưu ý rằng có rất nhiều điều phải học từ việc đọc mã xấu. Có thể cho rằng, đọc và làm theo mã xấu thậm chí còn khó khăn hơn so với việc đi sâu vào một dự án được tổ chức hợp lý. (Và đây là trước khi chúng ta cố gắng tìm ra mã "tốt" là gì. :))
Adam Lear

1
đủ đúng Nhưng đối với hầu hết chúng ta không phải là thiên tài, tự học có giới hạn. Hầu hết những người mới bắt đầu (trong tất cả các lĩnh vực) cần tiếp xúc với "điều tốt" để cảm nhận điều gì tốt. Và "Internet" là một câu nói hay của thế giới "Tôi tốt!", Điều đó không giúp ích gì.
Cris

10

Rất ít người viết mã nguồn tốt trong lần thử đầu tiên. Mã nguồn tốt thường được tạo ra bởi một loạt các sửa đổi. Do đó, nếu bạn có thể tìm thấy mã nguồn đã được đánh giá ngang hàng nhiều lần và cố định nhiều lần, có lẽ bạn đang ở một vị trí tốt hơn. Một số dự án nguồn mở (và một số phần trong số đó) được xem xét đặc biệt tốt. Mã đến từ các công ty có chu kỳ xem xét bắt buộc (ví dụ: Google nhưng có nhiều công ty khác) có thể phù hợp với dự luật.

Điều đó đang được nói, tôi không chắc mục tiêu của bạn sẽ là tìm "mã tuyệt vời". Nó nên được xem xét các kiểu mã khác nhau (chẳng hạn như các kiểu được viết bởi đồng nghiệp của bạn) và học cách xác định các điểm tốt và xấu về nó. Bạn càng xác định được nhiều điểm xấu, bạn sẽ càng nỗ lực để làm cho mã của mình tốt hơn và biết cách.

Cụ thể, tôi tin rằng một cách tiếp cận rất tốt để có được cảm giác về mã tốt là sử dụng trình gỡ lỗi tương tác để theo dõi thông qua mã phức tạp, theo chuỗi các lệnh. Ví dụ: đi đến một trong các tệp chính của công ty bạn, đặt điểm dừng và bắt đầu tìm hiểu mọi thứ từ chúng.

Sau một vài lần bạn bị mất phương hướng bởi các hàm 100 dòng với mười cấp độ thụt lề và phụ thuộc vào toàn cầu và một vài lần bạn lướt qua mã bị phân tách tốt, bạn sẽ cải thiện chương trình của riêng mình.


4

Thay vì tìm mã tuyệt vời, hãy nhìn vào Sách lập trình chung.

ví dụ: Hoàn thành mã, Viết mã vững chắc, Mẫu thiết kế (Tôi chắc chắn có rất nhiều sách khác xung quanh trong một câu hỏi và câu trả lời khác trong trang web này)

Những cuốn sách đang mô tả triết lý những gì được coi là mã tốt. Khả năng đọc, hiệu suất, bảo trì, phát hiện lỗi, vv

Điều này phục vụ một nguồn tài nguyên thậm chí tốt hơn và hiệu quả hơn là cố gắng tìm ra những gì tác giả đang cố gắng đạt được.

Thiết kế phần mềm tốt là những gì bạn nên xem xét là tốt. Điều này sẽ khó nhận ra chỉ từ việc quan sát mã, do dự án đủ lớn.


1
Tôi muốn đề cập đến "Clean Code" là một tài nguyên tốt.
mh

3

Tôi thấy rằng mã của các thư viện đi kèm với ngôn ngữ lập trình mà bạn lựa chọn thường là một khởi đầu tốt để xem những gì được cho là thực tiễn tốt nhất và phong cách mã hóa tốt.

Mặc dù bạn không muốn bắt đầu với những nơi như sắp xếp thuật toán hoặc các lớp container phức tạp.

Một nơi khác cho những hiểu biết thú vị trong việc viết mã là Project Euler ( http://projecteuler.net/ ). Bất lợi nhỏ ở đó: Bạn phải giải quyết vấn đề trước để có quyền truy cập vào diễn đàn nơi người khác đăng giải pháp của họ (những thách thức thú vị cho tất cả các cấp độ kinh nghiệm). Nhưng một khi đã hoàn thành, bạn sẽ tìm thấy các ví dụ cho gần như tất cả các ngôn ngữ lập trình chính. Và vì bạn đã giải quyết vấn đề này rồi, nó sẽ giúp bạn hiểu mã người khác. Thêm vào đó, bạn có thể xem mã ngôn ngữ bạn chưa biết, nhưng có thể thấy thú vị.


3

Tôi thực sự rất thích đọc Code đẹp . Nó có các ví dụ mã ngắn, nhưng rất đẹp với các giải thích chi tiết.

... Các nhà khoa học máy tính hàng đầu cung cấp các nghiên cứu trường hợp cho thấy cách họ tìm thấy các giải pháp được thiết kế cẩn thận khác thường cho các dự án cao cấp. Bạn sẽ có thể nhìn qua vai các chuyên gia thiết kế và mã hóa lớn để nhìn nhận vấn đề qua đôi mắt của họ.

... Các tác giả nghĩ to khi họ làm việc thông qua kiến ​​trúc dự án của họ, sự đánh đổi được thực hiện trong quá trình xây dựng và khi điều quan trọng là phải phá vỡ các quy tắc.

Cuốn sách này bao gồm 33 chương được đóng góp bởi Brian Kernighan, KarlFogel, Jon Bentley, Tim Bray, Elliotte Rusty Harold, Michael Feathers, Alberto Savoia, Charles Petzold, Douglas Crockford, Henry S. Warren, Jr., Ashish Gulhati, Lincoln Stein, Jim Kent , Jack Dongarra và PiotrLuszczek, Adam Kolawa, Greg Kroah-Hartman, Diomidis Spinellis, AndrewKuchling, Travis E. Oliphant, Ronald Mak, Rogerio Atem de Carvalho vàRafael Monnerat, Bryan Cantrill, Jeffan Otte và Douglas C. Schmidt, AndrewPatzer, Andreas Zeller, Yukihiro Matsumoto, Arun Mehta, TV Raman, Laura Wingerd và Christopher Seiwald, và Brian Hayes ...

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.