Làm thế nào bạn đã tìm thấy, tinh chế và duy trì phong cách mã hóa của bạn?


10

Gần đây, tôi đã chuyển đổi giữa một số dự án và môi trường phát triển. Các kỳ vọng cho phong cách mã hóa trong mỗi là khác nhau.

Bây giờ, câu hỏi của tôi là ba phần, phần đầu tiên, chỉ là sự tò mò:

  1. Làm thế nào bạn xác định và tìm thấy phong cách mã hóa của bạn?
  2. Làm thế nào để bạn tiếp tục tăng cường và cải thiện nó?
  3. Làm thế nào để bạn duy trì nó? (Từ ghi chú tinh thần, giữ tài liệu, sử dụng công cụ như StyleCop, v.v.)

Câu trả lời:


7

№1. # Làm thế nào bạn xác định và tìm thấy phong cách mã hóa của bạn?

Thông qua các mẫu mã đầu tiên trong sách, sau đó trong các văn bản và bài viết MSDN, sau đó là blog và các trang web khác.

№2. Làm thế nào để bạn tiếp tục tăng cường và cải thiện nó?

Tôi giữ cho mắt mở cho tất cả các đề nghị mọi người thực hiện. Tôi thử chúng, nếu chúng làm việc cho tôi, chúng dính vào. Thỉnh thoảng tôi cũng thử nghiệm, những gì dường như cải thiện mọi thứ ở lại với tôi.

№3. Làm thế nào để bạn duy trì nó? (Từ ghi chú tinh thần, giữ tài liệu, sử dụng công cụ như StyleCop, v.v.)

Tôi sắp xếp ghi nhớ phong cách của mình và áp dụng nó tự động ở mọi nơi.


Lưu ý 1. Giữ mắt mở và tai sắc nét là cực kỳ quan trọng để duy trì hiện tại. Nhiều năm trước tôi đã học được từ những người khác, ký hiệu Hungary là điều bắt buộc nên tôi đã làm theo. Khi cộng đồng nhận ra nó không tuyệt vời lắm, tôi đã thay đổi với mọi người.

Lưu ý 2. Điều quan trọng không phải là yếu tố phong cách cụ thể nào bạn áp dụng mà là bạn giữ phong cách nhất quán trong suốt mã của mình. Điều tương tự áp dụng cho một đội. Chọn một số phong cách nhưng sau đó dính vào nó.

Lưu ý 3. Kiểu mã hóa cho các ngôn ngữ khác nhau có thể khác nhau. C ++ xứng đáng với một phong cách, Java khác. HTML và CSS có các đặc điểm của chúng đòi hỏi một số phong cách khác nhau một lần nữa.

Lưu ý 4. Dù bạn chọn kiểu nào, hãy hiểu và chấp nhận rằng nó sẽ không hoạt động 100%. Đôi khi bạn có một số mã yêu cầu một kiểu khác chỉ tại chỗ, hoặc chia nhiều dòng, căn chỉnh khác nhau hoặc bất cứ điều gì để giữ cho đoạn mã cụ thể đó dễ đọc hơn. Đừng đẩy phong cách của bạn ở mọi nơi, tập trung vào khả năng đọc mã. Nếu rõ ràng, phong cách không hoạt động ở nơi đặc biệt này, hãy tạo một ngoại lệ.

Lưu ý 5. Đừng thực hiện theo kiểu mã theo tôn giáo. Các công cụ thực thi một kiểu mã là tốt, nhưng đôi khi có thể khiến bạn phát điên. Ví dụ, tôi đã vô hiệu hóa định dạng mã tự động của Visual Studio vì nó đang khiến tôi phát điên. Nếu một công cụ trở thành một trở ngại, chỉ cần thêm một ngoại lệ và đừng lo lắng rằng mã của bạn không tuân thủ 100%. Dù sao nó cũng không quan trọng lắm và sự hoàn hảo không thể đạt được.


+1 Số hai chính xác là cách tôi cải thiện (d) phong cách của mình.
Oliver Weiler

2
Chúa ơi, người đàn ông ... MSDN? Tôi khóc cho các đồng nghiệp của bạn ...
Shog9

1
  • Làm thế nào bạn xác định và tìm thấy phong cách mã hóa của bạn?

Tôi không nghĩ đã có lúc tôi nói: "Ok đây sẽ là phong cách của tôi". Tập trung vào môi trường hoặc ngôn ngữ cụ thể. Phong cách của bạn nên phản ánh cách bạn đối mặt với một vấn đề nhất định.

  • Làm thế nào để bạn tiếp tục tăng cường và cải thiện nó? Đọc blog của các nhà phát triển có thể hữu ích để xem những gì người khác đang làm việc, tìm kiếm phần mềm được sử dụng rộng rãi (nếu nó rất tốt, có thể bạn có thể sử dụng một số giải pháp của họ), v.v.
  • Làm thế nào để bạn duy trì nó? (Từ ghi chú tinh thần, giữ tài liệu, sử dụng một công cụ như StyleCop, v.v.) Câu hỏi này đặt ra một câu hỏi khác: Bạn có thể mất phong cách của mình không? Tôi nghĩ đó là một phần của bạn vì vậy bạn không thể, phải không?

1

Tôi đã làm việc trong một nhóm với một trò chơi nguồn đóng mà tôi yêu thích và nhà phát triển chính đã hướng dẫn tôi, và giúp tôi cải thiện các kỹ năng của mình sau khi tôi cũng hỏi anh ấy.

Anh ấy đề xuất và tôi đã áp dụng Kiểu mã hóa của Khung công tác Zend (http://framework.zend.com/manual/en/coding-st Chuẩn.html)


1

Tôi đã kết thúc việc áp dụng các đặc điểm của các phong cách khác nhau - bao gồm các phong cách được phản ánh trên MSDN. Sau đó tôi thiết lập các mẫu trong VS cung cấp #region/#endregioncác khối của tôi và bất kỳ thứ gì khác thích hợp hơn.

Tôi tiếp tục nghiên cứu các phong cách khác mà tôi gặp phải thông qua nghiên cứu và đọc. Nếu tôi nghĩ rằng có một cái gì đó nổi bật và có thể cải thiện phong cách của tôi về khả năng đọc, bảo trì hoặc tổ chức, tôi sẽ thử nó. Nếu điều chỉnh kiểu mới theo thứ tự, tôi sẽ cập nhật các mẫu trong VS hoặc ghi chú tinh thần.


1
  1. Đọc mã nguồn DOOM.
  2. Đọc mọi thứ khác tôi có thể đặt tay lên, chọn ra những phần làm việc.
  3. Chức năng nghiện rượu.

Khi viết mã một mình, tôi nhắm đến sự ngắn gọn; Lập trình Spartan có thể đã hoàn tất, sự điên rồ điên rồ ... Nhưng có lẽ đó là điều quen thuộc gần nhất với tín ngưỡng của tôi.

Khi mã hóa với những người khác, đặc biệt là mã hóa bảo trì, tôi đặt mục tiêu trở thành một con tắc kè hoa - những thay đổi của tôi sẽ cải thiện những gì họ sửa đổi, mà không cần nhìn ra chỗ khác.


1

Làm thế nào bạn xác định và tìm thấy phong cách mã hóa của bạn?

Bằng cách tập trung vào tính đơn giản và dễ đọc (khả năng đọc! == dễ hiểu, xem Lập trình Spartan )

Làm thế nào để bạn tiếp tục tăng cường và cải thiện nó?

Bằng cách xem xét mã của người khác và mã của riêng tôi (và thậm chí chính các tiêu chuẩn mã hóa).

Làm thế nào để bạn duy trì nó? (Từ ghi chú tinh thần, giữ tài liệu, sử dụng công cụ như StyleCop, v.v.)

Tôi sử dụng dokuwiki , một cách dễ dàng để thiết lập (không có cơ sở dữ liệu), cấu trúc phân cấp, điều khiển chi tiết (ACL ngoài hộp), ngoại hình thực sự đẹp và cũng là wiki, vì vậy bất kỳ ai cũng có thể đóng góp. Ngoài ra, đóng góp / thay đổi luôn được đồng thuận và biện minh, dựa trên sự đơn giản và dễ đọc.


Thật thú vị, tôi chưa bao giờ nghe nói về Lập trình Spartan, nhưng đó là những nguyên tắc tôi đã tuân theo bản năng; bây giờ tôi sẽ biết tên của nó, thật tuyệt :-)
wildpeaks

0

Đây là một câu trả lời kỳ lạ, nhưng tôi đã mất một thời gian rất dài để thực sự chọn lập trình. Tôi đã dành rất nhiều thời gian để làm việc trong "nghệ thuật" trước khi coi mình là một lập trình viên.

Khi viết mã, tôi có xu hướng suy nghĩ theo các đơn vị như viết - đoạn văn, cụm từ, v.v. Vì điều này, tôi sẽ trải rộng mã ra nhiều dòng hơn để theo đuổi làm cho nó dễ đọc như một câu chuyện / bài luận / v.v. Tôi thực sự khó chịu khi các nhà phát triển cố gắng nhồi nhét càng nhiều càng tốt vào một dòng hoặc vào một không gian nhỏ, bởi vì nó không hoàn thành bất cứ điều gì ngoài việc làm cho người viết cảm thấy thông minh và gây phiền nhiễu cho bất kỳ độc giả tương lai nào.

Nếu tôi cần làm điều gì đó kỳ lạ vì mục đích hiệu quả, tôi sẽ bình luận để giải thích tại sao nó lại như vậy.

Tôi có lẽ sẽ không nhận được bất kỳ sự ủng hộ nào cho việc này nhưng có lẽ điều này sẽ gây ra một số cuộc thảo luận.

Đối với khía cạnh kỹ thuật, như vị trí của dấu ngoặc và như vậy, tôi giữ chúng thẳng hàng vì kết quả là khả năng đọc tăng lên.


0

1. How did you define and find your coding style?

Tôi chấp nhận áp dụng một hướng dẫn phong cách đã được phát triển mà phần lớn được phát triển và chấp nhận rộng rãi hoặc phổ biến bởi một công ty / dự án lớn.

Tôi làm điều đó vì nhiều lý do, nhưng chủ yếu là vì các hướng dẫn phong cách như vậy có thể được các nhà phát triển chấp nhận ngay lập tức. Một hướng dẫn phong cách chỉ có giá trị như các nhà phát triển sẵn sàng gắn bó với nó.

Ví dụ như PEP 8 của Python , hướng dẫn về phong cách của Android cho Java , hướng dẫn kiểu jQuery Core hoặc hướng dẫn kiểu Python của Google .

2. How do you keep augmenting and improving it?

Lập luận lớn nhất cho các hướng dẫn phong cách như vậy là chúng không được phát minh ở đây và không được phát minh bởi tôi. Nó đã lấy điểm của các nhà phát triển, các dòng mã đáng sợ và nhiều thời gian hơn công ty / nhóm của bạn sẽ sẵn sàng đầu tư vào phát triển và duy trì một hướng dẫn phong cách.

Về phần cải tiến, chưa bao giờ có một hướng dẫn về phong cách trả lời ngay lập tức mọi thứ bạn có thể cần biết. Nhưng, trong hầu hết các trường hợp, những cải tiến mà tôi thấy được đẩy về phía trước chỉ là một phiên bản dài dòng hơn về những gì hướng dẫn phong cách đã được đưa ra với cách tiếp cận để viết mã.

Trong những trường hợp như vậy khi bạn gặp phải một khối wierdness, bạn nên dán nó vào một ý chính hoặc vào một số công cụ chia sẻ đoạn mã thích hợp khác với sự hỗ trợ cú pháp màu và thảo luận về nó ở đâu đó với các nhà phát triển khác. Điều tuyệt vời là trong những trường hợp như vậy, bạn không quan tâm đến mã làm gì, mà chỉ là cách mã xuất hiện, vì vậy bạn có thể đưa khối đó ra khỏi bối cảnh và thảo luận về cách bạn nên cải thiện nó, so sánh nó với những gì đã được chỉ định trong hướng dẫn phong cách như là điểm khởi đầu chính cho các cuộc thảo luận.

3. How do you maintain it?

Chà, điều tuyệt vời là bạn sẽ có các tài liệu hiện có được duy trì công khai trực tuyến.

Khi nói đến định dạng mã, bạn cũng có thể đi xa hơn và cung cấp cho nhóm của bạn các cấu hình định dạng cho trình soạn thảo yêu thích của họ, điều này sẽ giúp loại bỏ lỗi và phỏng đoán về việc duy trì sự xuất hiện hàng đầu. Trên thực tế, tôi sẽ không gọi nó đi thêm một dặm nữa, nhưng là một phần không thể thiếu của sự phát triển - không có gì tệ hơn khi thực hiện một sự khác biệt trong đó 90% thay đổi mã là một số người đăng ký mã được định dạng / định dạng đúng bởi vì ai đó đã quên làm sạch trước khi họ cam kết một tính năng mới rất lớn.


0

Nếu bạn là thành viên của một đội, bạn phải luôn luôn thêm vào tiêu chuẩn của đội. Có rất nhiều điều để nói là sử dụng một bố cục chung chứ không phải bố cục cá nhân của riêng bạn. Nó làm cho mã của bạn dễ đọc và dễ hiểu hơn bởi những người khác là điều cần thiết.

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.