Công việc của tôi đã yêu cầu tôi đọc khá nhiều mã được viết bởi những người khác, và trong những năm qua tôi đã thấy rằng có một số vấn đề mà có xu hướng tái diễn một lần nữa và một lần nữa. Ý tưởng với blog này là để viết lên một số lời khuyên về điều này một lần và cho tất cả, với hy vọng rằng nó có thể giúp người ra có những người đấu tranh để viết mã sạch sẽ.
Mục đích chính với những lời khuyên này là dễ đọc. Điều này quan trọng bởi vì thường thì mã của bạn đã được thay đổi hoặc xem lại bởi những người khác, và viết readably làm cho công việc của những người dân dễ dàng hơn nhiều. Đó có thể là rõ ràng. Cái gì chưa rõ ràng là nó cũng làm cho công việc của bạn dễ dàng hơn, bởi vì làm việc trên các mã đơn giản là dễ dàng hơn nhiều so với làm việc trên mã phức tạp, ngay cả khi bạn đang viết nó, và mã dễ đọc hơn là luôn luôn đơn giản.
Một phần quan trọng của việc mã của bạn có thể đọc được là phải luôn luôn làm việc để truyền đạt ý định của bạn. Ý tưởng cơ bản là nó thường không khó để thấy những gì một dòng mã nào. Điều khó khăn là để xem tại sao nó làm những gì nó làm. Vì vậy, bạn càng có thể làm cho mã của bạn truyền đạt những suy nghĩ đằng sau mã, thì tốt hơn là. Bạn sẽ thấy điểm này tái diễn nhiều lần dưới đây.
Tôi nên thêm rằng hầu hết mọi người dường như được nhận thức của hầu hết các quy tắc, trong một loại nói chung của con đường.Các điểm chính của việc này là thực sự gửi bài để thuyết phục mọi người rằng những quy tắc này rất quan trọng. Vì vậy, quan trọng, trong thực tế, mà bạn nên cố gắng để luôn luôn theo họ, và bạn cần phải có một lương tâm thật sự xấu về bất kỳ mã nào đó phá vỡ chúng. Vì vậy, xấu mà bạn chỉ cần không bao giờ viết bất kỳ mã đó. Một số những quy tắc này yêu cầu bạn phải viết một đoạn mã nhỏ thêm, nhưng tôi nghĩ rằng tôi có thể khẳng định rằng không ai trong số họ thực sự làm bạn mất thời gian, về dự án.
1. Luôn biết tại sao bạn bắt một ngoại lệ
Điều này đã được các sai lầm phổ biến nhất mà tôi thấy mọi người làm, và có vẻ như với tôi rằng trường hợp ngoại lệ là một tính năng nhiều người đã không thực sự học được cách sử dụng, chưa. Một trong những lý do cho điều này là rất có thể rằng trước khi sự ra đời của Java dân các ngôn ngữ được sử dụng ở trường đại học không có trường hợp ngoại lệ, và vì vậy không có quy tắc được dạy về việc này. Nó không phải là một tính năng tầm thường để sử dụng, vì vậy không ngạc nhiên khi người dân đấu tranh.
Dù sao, các quy tắc chính yếu là: nếu bạn bắt một ngoại lệ bạn cần phải có một lý do tốt. Báo cáo tình trạng lỗi sẽ cho người dùng một cách thân thiện hơn là một lý do tốt. Xử lý một dự kiến, nhưng không bình thường, điều kiện là khác. Nhưng thường người ta chỉ nuốt những trường hợp ngoại lệ với một khối catch rỗng (đây là một nono thực), hoặc họ làm như thế này:
Danh sách các tin tĩnh readlines (String filename) { Dòng String; ArrayList file = new ArrayList (); try { BufferedReader trong = new BufferedReader (new FileReader (filename)); trong khi ((dòng = in.readLine ())! = null) file.add (dòng); in.close (); } Catch (Exception e) { System.out.println (e); trở về null; } trở về tập tin; }
Các khối catch ở đây không có gì hữu ích. Trong thực tế, nó ẩn thông tin hữu ích nếu chương trình đã sụp đổ. Nếu bạn không nắm bắt những ngoại lệ, bạn sẽ có được một traceback. Nếu bạn bắt nó bạn sẽ có được ít hơn nhiều. Plus, nó chiếm 5 dòng, và nó làm cho các phương pháp gần như gấp hai lần lớn như nó cần phải được. Làm mà không chỉ là tốt hơn rất nhiều.
Điều đó sẽ cho chúng ta điều này:
tin readlines tĩnh ArrayList (String filename) throws IOException { Dòng String; ArrayList file = new ArrayList (); BufferedReader trong = new BufferedReader (new FileReader (filename)); trong khi ((dòng = in.readLine ())! = null) file.add (dòng); in.close (); trở về tập tin; }
2. Không bao giờ thực hiện kê khai các loại
Đây là một điều tôi thấy rất thường xuyên: tham số, biến, hoặc thậm chí quay trở lại các loại được thực sự thực hiện các loại. Bạn có thể thấy điều này trong đoạn mã trên, nơi mà ArrayList được sử dụng hợp Danh sách sẽ làm gì. Có một số vấn đề với điều này:ArrayList được lâu hơn, và bạn phải làm rất nhiều công việc nếu bạn muốn thay đổi danh sách những gì thực hiện bạn đang sử dụng.
Điều chính, tuy nhiên, là chỉ sử dụng danh sách liên lạc ý định của bạn rằng đây là một danh sách nhiều hơn nữa rõ ràng. Nó nói: "Tôi nghĩ về điều này, và tôi thực sự có ý định bộ sưu tập này được một danh sách, và không chỉ bất kỳ loại của bộ sưu tập". Nói cách khác: nó cho người đọc mà bạn quan tâm đến thứ tự trong bộ sưu tập này.
Một vòng đơn giản hóa giúp chúng ta điều này:
Danh sách các tin readlines tĩnh (String filename) throws IOException { Dòng String; Danh sách các file = new ArrayList (); BufferedReader trong = new BufferedReader (new FileReader (filename)); trong khi ((dòng = in.readLine ())! = null) file.add (dòng); in.close (); trở về tập tin; }
3. Sử dụng tên biến mô tả
Đây là một quy tắc có thể được khó để làm theo, nhưng trong các biến nói chung nên được đặt tên là để họ làm cho nó rõ ràng những gì một biến chứa. Đôi khi điều này là blindingly rõ ràng, và trong những trường hợp này tên ngắn như tôi đối với chỉ số vòng lặp, ở cho các tập tin là hoàn toàn OK. Nhưng nếu bạn sử dụng một tên dài hơn, cố gắng để làm cho nó có ý nghĩa.
Trong trường hợp của phương pháp trên, tập tin không thực sự có những gì? Có, nó có chứa các tập tin, nhưng những gì nó thực sự là là một danh sách tất cả các dòng trong tập tin. Vậy tại sao không gọi nó là dòng? Điều đó sẽ cho chúng ta:
Danh sách các tin readlines tĩnh (String filename) throws IOException { Dòng String; Danh sách các dòng = new ArrayList (); BufferedReader trong = new BufferedReader (new FileReader (filename)); trong khi ((dòng = in.readLine ())! = null) lines.add (dòng); in.close (); đường trở về; }
Vẫn không hoàn hảo, nhưng cho là dễ đọc hơn rất nhiều so với ban đầu.
4. Cut-và-dán mã
Một phương pháp đơn giản đó là gợi ý khá thường xuyên như một cách để cải thiện mã của mọi người là để vô hiệu hóa chức năng dán trên mỗi máy phát triển. Trong khi các ý tưởng có thể là một chút trên đầu trang, tư tưởng cơ bản là âm thanh. Nếu bạn có một đoạn, nói, 7 dòng mã mà làm một việc, và bạn muốn làm điều đó một lần nữa để một tập hợp khác nhau của các biến, không sao chép và dán mã. Thay vào đó, thực hiện một chức năng (hoặc một phương pháp, nếu bạn đang mắc kẹt với Java).
Có nhiều lý do cho việc này. Một là đơn giản, ngắn gọn. Khác là nó làm cho mã của bạn dễ dàng hơn để đọc, kể từ khi bạn có hiệu quả sẽ được thay thế 14 dòng mã với chỉ 2. Điều này rõ ràng sẽ là lúc các chi phí của một chức năng bổ sung / phương pháp, nhưng kể từ khi các đứng một mình và cô lập với phần còn lại của mã này, tác động của chúng có thể đọc được là rất thấp. Lý do chính, tuy nhiên, là bằng cách làm này, bạn làm cho cuộc sống dễ dàng hơn nhiều cho chính mình. Ngay cả nếu điều này là một kịch bản một lần, bạn vẫn sẽ thay đổi mã xung quanh. Điều này là dễ dàng hơn nếu nó được chia thành các bộ phận, như chức năng / phương pháp.
5. Các biến và truyền thông
Một trong những điều khó khăn nhất để nhận khi đọc code là để hiểu được dòng chảy của các giá trị thông qua các biến trong các mã. (Đây là một trong những lý do tại sao chức năng lập trình được phổ biến.) Này có ý nghĩa nhiều đối với các mã như thế nào nên được bằng văn bản.
Thứ nhất, điều này có nghĩa rằng bạn nên cố gắng để khai báo các biến như là gần nơi chúng được sử dụng càng tốt. Hãy nói rằng bạn viết như sau:
String tmp = null; / / 50 dòng không liên lạc tmp tmp = bất cứ điều gì; / / ...
Điều này có nghĩa là người đọc có thể quét 50 dòng để xem tmp được sử dụng bất cứ nơi nào trong đó. Sáp nhập chuyển nhượng và kê khai sẽ loại bỏ hoàn toàn vấn đề này, và sẽ mất bạn không có gì.
Một điều nữa phương tiện này là nếu một biến chỉ được sử dụng bên trong một khối (nếu tuyên bố, trong khi vòng lặp, hoặc bất cứ điều gì), sau đó nó thực sự cần được khai báo trong đó. Hãy tưởng tượng bạn viết này:
int tmp; cho (...) { / / Mã có sử dụng tmp } / / Không có nhiều đề cập đến các tmp dưới thời điểm này
Trong trường hợp này, bạn có thể đã tuyên bố tmp bên trong vòng lặp for. Không làm nó sẽ gửi tín hiệu rằng "Tôi sẽ tiếp tục sử dụng biến này" và lực lượng người đọc để cố gắng tìm ra những gì xảy ra với nó sau này. Di chuyển các khai báo trong vòng lặp nghĩa là bạn không thể sử dụng các biến sau khi các vòng lặp, mà làm cho mã dễ dàng hơn để đọc.
Một hệ quả thứ ba là bạn thực sự cần làm việc chăm chỉ để giữ cho các chức năng của bạn / phương pháp ngắn. Nếu bạn có một hàm / phương thức đó là, nói, 400 đường dài nó sẽ trở thành gần như không thể theo dõi lưu lượng dữ liệu thông qua nó. Có sẽ chỉ được biến quá nhiều và bài tập quá nhiều để theo dõi. Vì vậy, đây là một thực tế không-không. Chỉ cần không làm điều đó. Và như thường lệ với những quy tắc này, đây là một quy luật đó cũng sẽ giúp bạn có được mã phải lần đầu tiên, vì vậy đây là đáng làm, ngay cả nếu bạn chỉ sẽ viết code và sau đó loại bỏ nó.
Trong thực tế, nếu bạn thực sự giữ các phương pháp của bạn ngắn, rất nhiều quy tắc khác ở đây trở nên ít quan trọng, bởi vì tác động của việc chia nhỏ chúng sẽ được giảm đi. Lý do là tất nhiên rằng nó rất khó khăn cho một phương pháp ngắn để được thực sự khó đọc. Có rất ít mã trong một phương pháp ngắn mà bạn hầu như luôn luôn có thể tiêu hóa nó khá dễ dàng. Vì vậy, bạn có thể nghĩ về điều này như là các quy tắc quan trọng nhất.
6. Không bảo tồn các giá trị trả lại bạn không sử dụng
Điều này cũng liên quan đến làm cho nó dễ dàng hơn để theo dõi lưu lượng dữ liệu. Hãy nói rằng bạn viết như thế này:
boolean hiện tại = myCollection.remove (đối tượng); Bạn có thể viết nó như thế này, tuy nhiên:
myCollection.remove (đối tượng); Bạn có thể thừa nhận rằng bất kỳ người đọc của mã của bạn sẽ biết điều này, và do đó bằng cách sử dụng các hình thức đầu tiên là một tín hiệu rằng: "Tôi quan tâm đến giá trị này trở lại, và tôi sẽ sử dụng nó cho một cái gì đó". Nếu bạn không, bạn sẽ được gây nhầm lẫn cho người đọc, bởi vì họ giả định rằng họ bây giờ cần phải tìm ra những gì bạn sẽ làm gì với biến này.
Tất nhiên, để nó ra tiết kiệm không gian, quá, do đó, thực sự không có lý do để không thả các biến này.
7. Bỏ qua mã không cần thiết!
Đó là khá phổ biến để tìm mã đó là nhận xét ra, nhưng vẫn còn treo xung quanh. Điều này chủ yếu là xấu vì nó bloats mã không cần thiết. Mọi người dường như để làm điều này vì họ muốn có khả năng mang mã trở lại, hoặc là vì họ đang viết một sự thay thế họ không chắc chắn về, hoặc (và điều này có vẻ khá phổ biến) bởi vì họ không dám xóa nó. Tuy nhiên, trong gần như tất cả các trường hợp không có lý do thực sự để giữ mã như trên. Bạn nên sử dụng điều khiển phiên bản, và đó có nghĩa là bạn luôn có thể tìm thấy bất kỳ mã bị xóa một lần nữa.
Ngoài ra, kể từ khi mã này không còn biên soạn hoặc thực hiện không có khác biệt thực sự giữa các bình luận nó ra hay xóa nó.Bạn đã vẫn thực hiện thay đổi. Sự khác biệt là bây giờ nó rất có thể những mã này sẽ từ từ di chuyển ra khỏi đồng bộ với mã xung quanh nó, để đến lúc bạn tìm thấy bạn muốn nó một lần nữa nó sẽ không còn làm việc. Điều đó thực sự làm cho các mã nguy hiểm, bởi vì nó khiêu khích bạn bao gồm các mã mà không hiểu những gì nó làm. (Nếu bạn thực sự hiểu nó, bạn có thể nhập lại nó khá nhanh chóng ngay cả khi nó đã được xóa.)
Tất nhiên, nhận xét ra mã trong khi bạn đang làm việc trên các mã được tốt. Tôi làm điều đó rất nhiều. Tuy nhiên, tôi không bao giờ kiểm tra mã số đó là nhận xét ra, và mỗi khi tôi tìm mã đó tôi xóa nó, mà không yêu cầu bất cứ ai hay nói cho họ. Nếu họ muốn mã họ không nên có nhận xét nó ra. Và nó sẽ được trong lịch sử của phiên bản, anyway.
Không có nhận xét nào:
Đăng nhận xét