Là áp đặt định dạng mã giống nhau cho tất cả các nhà phát triển là một ý tưởng tốt?

Chúng tôi đang xem xét áp đặt một định dạng mã tiêu chuẩn duy nhất trong dự án của chúng tôi (định dạng tự động với các hành động lưu trong Eclipse). Lý do là hiện tại có một sự khác biệt lớn trong các định dạng mã được sử dụng bởi một số nhà phát triển (> 10), khiến cho một nhà phát triển khó làm việc hơn với mã của nhà phát triển khác. Cùng một tệp Java đôi khi sử dụng 3 định dạng khác nhau.

Vì vậy, tôi tin rằng lợi thế là rõ ràng (khả năng đọc => năng suất) nhưng nó sẽ là một ý tưởng tốt để áp đặt điều này? Và nếu không, tại sao?

CẬP NHẬT
Tất cả chúng ta đều sử dụng Eclipse và mọi người đều biết về kế hoạch này. Đã có một định dạng mã được sử dụng bởi hầu hết nhưng nó không được thi hành do một số thích bám vào định dạng mã của riêng họ. Vì những lý do trên, một số người thích thực thi nó.

Tôi hiện đang làm việc tại một nơi mà định dạng mã tiêu chuẩn được thi hành và mã được tự động định dạng khi lưu tệp, giống như bạn sắp làm. Là một thành viên mới của công ty, tôi thấy rằng các quy tắc định dạng phổ biến mang lại cho tôi cảm giác ấm áp và mờ nhạt rằng "những người này biết họ đang làm gì", vì vậy tôi không thể hạnh phúc hơn. ;) Như một lưu ý phụ có liên quan, với các quy tắc định dạng phổ biến, chúng tôi cũng thực thi một số cài đặt cảnh báo trình biên dịch khá nghiêm ngặt trong Eclipse, với hầu hết chúng được đặt thành Lỗi, nhiều cài đặt thành Cảnh báo và hầu như không được đặt thành Bỏ qua.

Tôi muốn nói có hai lý do chính để thực thi một định dạng mã trong một dự án. Trước tiên phải thực hiện với kiểm soát phiên bản: với mọi người định dạng mã giống hệt nhau, tất cả các thay đổi trong tệp được đảm bảo có ý nghĩa. Không còn chỉ là thêm hoặc xóa một khoảng trắng ở đây hay ở đó, chứ đừng nói đến việc định dạng lại toàn bộ tệp dưới dạng "tác dụng phụ" của việc thực sự thay đổi chỉ một hoặc hai dòng.

Lý do thứ hai là nó loại bỏ các bản ngã của các lập trình viên ra khỏi phương trình. Với mọi người định dạng mã của họ theo cùng một cách, bạn không còn có thể dễ dàng biết ai đã viết gì. Mã trở thành tài sản chung và ẩn danh hơn, vì vậy không ai cần phải cảm thấy khó chịu về việc thay đổi mã "của người khác".

Đó là những lý do chính, có những người khác là tốt. Tôi thấy an ủi rằng tôi không phải bận tâm đến việc suy nghĩ về định dạng mã, vì Eclipse sẽ tự động làm điều đó cho tôi khi tôi lưu. Không cần quan tâm, như viết tài liệu với LaTeX: nó được định dạng sau đó và bạn không phải lo lắng về điều đó trong khi viết. Tôi cũng đã làm việc trong các dự án mà mọi người đều có phong cách riêng của họ. Sau đó, bạn phải suy nghĩ về các vấn đề ngu ngốc và vô nghĩa như liệu có ổn không khi sửa đổi mã của người khác theo phong cách của riêng bạn hoặc thay vào đó bạn nên cố gắng bắt chước phong cách của họ.

Đối số duy nhất chống lại các cài đặt định dạng mã phổ biến mà tôi có thể nghĩ cho trường hợp của bạn là nó rõ ràng là một dự án đang diễn ra, vì vậy nó sẽ gây ra nhiều thay đổi không cần thiết trong tất cả các tệp, làm rối loạn lịch sử tệp thực tế. Kịch bản trường hợp tốt nhất là nếu bạn có thể bắt đầu thực thi các cài đặt ngay từ khi bắt đầu dự án.

Mỗi nhà phát triển phần mềm chuyên nghiệp sẽ thích áp dụng một tiêu chuẩn (tốt) hơn là tham gia vào các cuộc chiến truyền giáo theo phong cách, vì những lý do mà bạn đã vạch ra.

Nhiều nhà phát triển phần mềm tiến hành các cuộc chiến truyền giáo ......

Tùy thuộc vào vị trí của bạn trong đội và sự năng động của đội, bạn có thể quyết định rằng chiến thắng cuộc chiến là không thể. Trong trường hợp này, tốt nhất không nên bắt đầu ...

Vâng, thật tốt khi có một kiểu định dạng mã cho tất cả các nhà phát triển.

Thiết kế các định dạng kiểu mã và nhập nó cho tất cả các nhà phát triển nhật thực.

Điều này sẽ giúp ích khi chúng tôi mergingmã hóa hệ thống 'Kiểm soát phiên bản'.

Bạn đang cố gắng đạt được điều gì, bạn sẽ giữ được hậu môn như thế nào trong việc thực thi nó (và ở mức độ chi tiết, "quy tắc" của bạn sẽ được đặt ra), bạn sẽ cố gắng thực thi nó trên mã được viết bằng các ngôn ngữ khác nhau, bạn sẽ cố gắng thực thi nó hồi tố trên mã hiện có?

1. Một cái nhìn và cảm nhận chung về mã thực sự có thể giúp làm cho mã dễ đọc hơn, nhưng cũng có thể làm cho mọi thứ tồi tệ hơn nếu đó là giao diện sai. _hUngarian_lpfstr ký hiệu là một ví dụ điển hình :)
2. Tôi đã thấy "tiêu chuẩn mã" thực thi số lượng khoảng trắng giữa các khối nhận xét, thứ tự chữ cái của tên phương thức và các thứ vô nghĩa khác. Đừng làm vậy.
3. Các ngôn ngữ khác nhau có các tiêu chuẩn khác nhau mà mọi người đã quen với những người có kinh nghiệm sử dụng. Một số thậm chí bắt buộc các tiêu chuẩn này (nghĩ rằng Python, Cobol, Visual Studio tự động áp đặt các quy ước giằng kiểu C ++ trong khi Java sử dụng kiểu C theo quy ước, v.v.).
4. không bao giờ thay đổi mã hiện có để thay đổi mã, bạn chỉ giới thiệu các vấn đề mới theo cách đó. Và điều đó có nghĩa là các phần mã cũng như toàn bộ tệp nguồn. Vì vậy, đừng đi xung quanh việc định dạng lại mã hiện có khi ai đó thay đổi một dòng trong tệp 1000 dòng.
5. Các lập trình viên có kinh nghiệm có thể làm việc hiệu quả hơn nhiều nếu họ không phải suy nghĩ một nửa thời gian cho dù những gì họ viết sẽ "nhìn đúng" với hệ thống phê duyệt tự động hay người đánh giá. Họ cũng sẽ có thói quen viết mã sạch đơn giản vì đó là những gì hoạt động, ngay cả khi có sự khác biệt nhỏ giữa các phong cách tự nhiên của họ.

Vì vậy, trong khi có những lý do chính đáng để áp đặt một phong cách và tiêu chuẩn cụ thể, thì cũng có những lý do chính đáng để không làm như vậy (quá) một cách nghiêm ngặt.

Vâng, tính nhất quán là một ý tưởng tốt, vì lý do người khác đã đề cập .

Tôi chỉ muốn thêm một vài điểm chưa được sử dụng ở nơi khác:

• Oracle đã xuất bản một bộ các quy ước cho Java, đây là tiêu chuẩn thực tế.
  • Sử dụng những điều này sẽ giúp bạn tránh tranh luận về việc nên theo phong cách nào.
  • Rất nhiều thư viện công cộng và các dự án nguồn mở có xu hướng sử dụng các quy ước này, vì vậy khi bạn cần xem các định dạng đó sẽ quen thuộc.
  • Trình định dạng Eclipse có các quy tắc dựng sẵn để khớp với các quy ước này, điều này cũng có ích.
• Bạn có thể muốn xem xét việc xây dựng một hook trong thiết lập kiểm soát nguồn của mình để mã được tự động định dạng trước khi nó vào nhánh chính.
  • Bạn có thể tránh các trận chiến với các lập trình viên đặc biệt cứng đầu, những người từ chối tuân theo tiêu chuẩn. Họ thậm chí có thể sử dụng định dạng của riêng họ trong khi họ làm việc, sẽ được chuẩn hóa sau này!
  • Nếu bạn kết thúc bằng cách sử dụng cài đặt định dạng tùy chỉnh (ví dụ: nhiều người bỏ qua quy ước "tối đa 80 ký tự trên mỗi dòng"), bạn chỉ phải thực hiện thay đổi ở một nơi.

Tôi đã ở trong một nhóm sử dụng plugin Checkstyle . Thay vì sử dụng các tính năng vượt trội, chúng tôi đã thành lập một ủy ban nhỏ gồm các nhà phát triển quan tâm. Chúng tôi đã tranh luận về những gì dường như còn thiếu, những gì dường như quá mức và làm hỏng mọi thứ. Tất cả chúng ta đã học được điều gì đó trong quá trình, và củng cố những cơ bắp của nhà phát triển.

.

Khi chúng tôi có đánh giá mã, một trong những câu hỏi đầu tiên là: "Bạn đã chạy nó qua Checkstyle chưa?" Việc tuân thủ các tiêu chuẩn mã hóa phần lớn được tự động hóa và nó đã thu hút sự chú ý từ người đánh giá là kén chọn. Thật dễ dàng để Checkstyle làm nổi bật chữ ký phương thức, nhấp chuột phải và thay đổi một biến thành cuối cùng. Nó cũng có thể sửa các vết lõm và dấu ngoặc để mã của mọi người có giao diện giống nhau. Thiếu một Javadoc cho một chức năng công cộng? Checkstyle sẽ gắn cờ chức năng.

(Loại bỏ mùi mã quan trọng hơn định dạng nhất quán. Đây là lợi ích của các công cụ tự động.)

Tôi sẽ đặt các công cụ tự động như Checkstyle ít hơn là áp đặt cùng định dạng và hơn thế nữa vào việc khuyến khích một giao diện tương tự. Và khi bạn chăn mèo, một công cụ tự động có thể giúp mài giũa kỹ năng và giảm mùi mã mà không làm bầm dập những cái tôi mong manh.

Nếu bạn sẽ gắn bó với cùng một IDE và kết hợp một số công cụ định dạng, thì đó là một ý tưởng hay vì bạn không cần quá nhiều nỗ lực. Giữ các quy tắc đơn giản với sự tập trung vào khả năng đọc và không giữ lại hậu môn . Đó nên là thanh đo.

Mặc dù một quả bóng bùn được tạo thành một cách nhất quán tốt hơn là một quả bóng bùn, thời gian của bạn sẽ tốt hơn dành cho việc cắt nó ra thay vì quá kén chọn về nơi mà các dấu ngoặc đi. Đừng biến thành người quản lý đầu pin, người cảm thấy như họ đang thực hiện công việc của mình bằng cách đếm các khoảng trống thụt lề trong quá trình đánh giá mã cùng với việc đảm bảo các trang bìa mới có trên Báo cáo TPS .

Sở thích cá nhân chỉ có vậy và hiếm khi cải thiện sản xuất: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Nếu có, hãy vượt qua nó và hoàn thành công việc.

Tôi thực sự khuyên mọi người nên thực thi định dạng mã và các vi phạm nhỏ sẽ bị bỏ qua hoặc chạm vào. Lý do cho điều này là, ngắn gọn,

1. Máy bị lỗi ở thời điểm tồi tệ nhất có thể và thông thường khi bạn đang sử dụng một tính năng ngôn ngữ mới. Làm thế nào nó sẽ xử lý các bao đóng trong Java, v.v. Jalopy có vấn đề với enums với các chức năng thành viên.
2. Tôi nghĩ rằng đó là một gánh nặng rất hợp lý để đặt lên lập trình viên để vui lòng sản xuất mã cho công ty trông giống như mã công ty. Tôi thấy hữu ích khi đề cập rằng đây là cách mã được định dạng "ở đây", chứ không phải cách tất cả mã phải được định dạng ở mọi nơi. Công ty trước của họ có thể đã chọn một con đường khác, và điều đó ổn. Không giống như ngôn ngữ bản địa, có những thành ngữ dành riêng cho văn hóa mã của bạn mà bạn muốn đưa ra.
3. Việc thực thi cú pháp mã được thực hiện tốt nhất với các đánh giá mã:
   1. Nếu định dạng là quan trọng, nó sẽ thu hút tổ chức của bạn thực hiện đánh giá mã. Đây là lợi ích rất lớn.
   2. Nếu một quy tắc định dạng bị phá vỡ, một con người có thể nhìn vào nó và phán đoán tốt hơn một cỗ máy nếu ý định được truyền đạt rõ ràng hơn. Điều này rất hiếm, nhưng đôi khi xảy ra.

Về "khả năng đọc => năng suất", cấu trúc mã (như các lớp và hàm chịu trách nhiệm đơn) sẽ mua cho bạn nhanh hơn nhiều so với định dạng mã. Định dạng mã có thể là một trợ giúp, nhưng những suy nghĩ khác nhau phân tích các câu lệnh khác nhau - không phải ai cũng sẽ "làm việc hiệu quả hơn". Tôi muốn nhân đôi cấu trúc mã qua định dạng bởi vì đó là điều cũng sẽ kéo bạn vào việc đánh giá mã và khiến nhóm suy nghĩ về cách chương trình hoạt động, chứ không phải là một vòng lặp đơn lẻ.

Tôi không phải là một fan hâm mộ lớn của Thiết kế hướng miền, nhưng đây là một mô hình gần đây có ý tưởng RẤT rõ ràng về cách mã phải được cấu trúc và các quy ước định dạng mã chảy tự nhiên ra khỏi chương trình có cấu trúc Thiết kế hướng miền. Một lần nữa ... Tôi không thích DDD, nhưng đó là một ví dụ tuyệt vời vì nó được xác định rõ ràng.

Tôi cho rằng chủ đề của câu trả lời này là, Thực hiện đánh giá mã và để định dạng chảy từ văn hóa và ra khỏi quá trình xem xét.

Nói chung, giả sử bạn thuê các nhà phát triển hợp lý, việc áp dụng một định dạng mã phổ quát là một ý tưởng tồi. Tuy nhiên, đó là một ý tưởng tốt để áp dụng các hướng dẫn mã .

Tôi chưa bao giờ thấy một bộ quy tắc định dạng mã nào tối ưu hóa khả năng đọc trong mọi trường hợp. Tương tự như vậy, không có quy tắc ngữ pháp áp dụng 100% bằng tiếng Anh: bộ não của chúng ta không có dây theo cách đó. Vì vậy, sử dụng các hướng dẫn, nhưng cung cấp cho các nhà phát triển sự tự do để ghi đè chúng khi họ thấy phù hợp.

Điều đó đang được nói, một quy tắc khó hơn của "tuân theo quy ước mã đã tồn tại trong tệp / dự án" là một quy tắc tốt.

Nhưng hãy nhớ rằng định dạng đóng góp ít hơn cho khả năng đọc hơn là cách đơn giản để tổ chức mã một cách hợp lý. Tôi đã thấy rất nhiều mã spaghetti không thể đọc được với định dạng hoàn hảo!

Tôi không nghĩ rằng có một câu trả lời đơn giản cho điều này. Đó không phải là một câu hỏi có hay không. Mặc dù tôi tin rằng các quy ước về phong cách và đặt tên rất quan trọng ở một mức độ nào đó, nhưng cũng khá dễ dàng để lãng phí quá nhiều thời gian nghĩ về nó. Tốt nhất là trả lời bằng ví dụ.

Trong một dự án cụ thể mà tôi đã tham gia, không có quy ước nào cả. Mỗi nhà phát triển đã làm mọi thứ theo cách riêng của họ. Bởi vì sự thiếu kinh nghiệm tương đối của đội này, đi từ lớp này sang lớp khác thực sự rất chói tai. Phong cách là một vấn đề ít hơn so với vấn đề quy ước đặt tên. Một nhà phát triển sẽ tham chiếu các yếu tố UI với ký hiệu tiếng Hungary khủng khiếp (một thực tế ngớ ngẩn trong thời đại của IDE hiện đại), một người sẽ đặt tên cho các thành viên tư nhân theo một cách, một người khác sẽ đặt tên cho họ theo cách khác. Bạn chỉ không bao giờ biết những gì bạn đang nhìn.

Ở thái cực ngược lại, một nhóm đã sử dụng StyleCop (đây là một dự án .Net) như một phần của quá trình xây dựng của họ. Điều tồi tệ hơn là họ cũng đã sử dụng hầu hết các quy tắc mặc định. Vì vậy, bạn sẽ làm một cái gì đó hoàn toàn bình thường về khoảng cách dòng hoặc vị trí khung cong, và bản dựng sẽ khó chịu vì nó. Quá nhiều thời gian đã bị lãng phí khi chỉ thêm không gian và dòng vào công cụ, và tất cả mọi người, bao gồm cả những anh chàng khăng khăng sử dụng StyleCop, cuối cùng đã thực hiện nó gần như mọi cam kết. Đó là một sự lãng phí rất lớn thời gian và tiền bạc.

Vì vậy, vấn đề tôi đưa ra ở đây là không linh hoạt không phải là câu trả lời, nhưng ở miền Tây hoang dã cũng không. Câu trả lời thực sự là tìm ra nơi có ý nghĩa nhất, mà theo tôi là không có công cụ tự động kiểm tra công cụ, nhưng cũng không ném quy ước vào gió.

Lập luận chính của tôi chống lại phong cách mã hóa phổ biến là một lập trình viên có kinh nghiệm được sử dụng để đọc phong cách của riêng mình. Bạn có thể đào tạo tay để viết một phong cách cụ thể nhưng gần như không thể đào tạo mắt để hiểu một phong cách mà bạn ghét. Một lập trình viên viết một số đoạn mã một lần và sau đó đọc nó nhiều lần trong quá trình phát triển và gỡ lỗi. Nếu mỗi lần anh ta đọc mã của mình, anh ta đấu tranh để hiểu nó vì anh ta buộc phải viết nó theo kiểu BAD, anh ta sẽ rất không vui và kém năng suất. Đây là từ kinh nghiệm của tôi.

Tôi không quá quen thuộc với Eclipse nhưng định dạng tự động khi lưu âm thanh giống như một ý tưởng khủng khiếp. Một nhà phát triển phải có toàn quyền kiểm soát mã của mình bất kể phong cách mã hóa có được áp đặt hay không. Hoạt động 'lưu' không được thay đổi một ký tự mà không có sự đồng ý rõ ràng từ người dùng.

Nếu công ty của bạn bán mã nguồn thì phong cách mã hóa là quan trọng hơn nhưng nếu bạn bán mã được biên dịch thì nó ít liên quan hơn nhiều.

Hy vọng rằng phong cách mã hóa sẽ làm cho lập trình viên gốc không thể phân biệt và ngăn chặn các cuộc chiến bản ngã là nhảm nhí trong trường hợp tốt nhất và ngu ngốc rõ ràng trong trường hợp xấu nhất. Các lập trình viên tuyệt vời sẽ luôn tạo ra mã thanh lịch bất kể phong cách.

Tôi cũng rất ủng hộ việc trao cho mọi nhà phát triển quyền sở hữu các đơn vị mã cụ thể và chống lại việc cho phép mọi người chạm vào mọi đoạn mã một cách tự do. Phát triển toàn bộ các đơn vị trong mã và chịu trách nhiệm về chúng cho phép nhà phát triển phát triển niềm tự hào về công việc của mình và ngăn anh ta phát triển mã tào lao khi biết rằng các lỗi sẽ quay trở lại để săn lùng anh ta.

Cuối cùng, bất cứ ai theo phong cách mã hóa chuyên nghiệp luôn cho rằng phong cách mã hóa của riêng mình sẽ được chọn và mọi người khác sẽ làm theo. Hãy tưởng tượng rằng phong cách mã hóa mà bạn thích nhất từ ​​tất cả các nhà đồng phát triển được chọn là tiêu chuẩn. Bạn vẫn ủng hộ phong cách mã hóa?

Một định dạng để cai trị tất cả ... nó có thực sự tối ưu không?

Nó giống như lái xe của người khác ...

Chắc chắn bạn có thể nhảy vào và lái bất kỳ chiếc xe nào, nhưng bạn sẽ an toàn hơn, thoải mái hơn và ít gặp sự cố hơn nếu bạn dành thời gian để điều chỉnh ghế ngồi, vô lăng và gương theo sở thích của BẠN .

Với mã, định dạng sẽ ảnh hưởng đến sự thoải mái của bạn trong việc đọc và hiểu mã. Nếu nó quá xa so với những gì bạn đã quen với nó sẽ đòi hỏi nhiều nỗ lực tinh thần hơn. Có cần thiết phải gây ra điều này cho các nhà phát triển?

+1 cho tất cả các lợi ích được đề cập cho đến nay, nhưng ...

Thực thi tự động đi kèm với chi phí cần được xem xét:

-1 với thực tế là các trình định dạng mã không hiểu tính thẩm mỹ của định dạng mã. Đã bao nhiêu lần bạn có một trình định dạng mã phá hủy một khối nhận xét được căn chỉnh độc đáo trong một dạng bảng? Đã bao nhiêu lần bạn cố tình căn chỉnh một biểu thức phức tạp theo một cách nhất định để tăng khả năng đọc, chỉ để định dạng tự động đưa nó vào một cái gì đó "tuân theo các quy tắc", nhưng lại khó đọc hơn nhiều ?

Đôi khi có những cách giải quyết cho những điều này, nhưng các nhà phát triển có những điều quan trọng hơn để đặt tâm trí của họ hơn là làm thế nào để giữ cho trình định dạng tự động không bị xáo trộn mã.

Có quy tắc định dạng, nhưng cho phép một số tự do để áp dụng ý thức chung.

Các nhà phát triển giỏi là những người sáng tạo, cung cấp cho họ một số giấy phép nghệ thuật. "Giữ cho nó đơn giản" nên là câu thần chú của các lập trình viên. Tôi có hai quy tắc:

Quy tắc 1: Đưa ra các biến / con trỏ / đối tượng / thủ tục / bất cứ tên SENSIBLE nào. Tên rõ ràng mang lại ý nghĩa và sự hiểu biết cho mã của bạn.

Quy tắc 2: Sử dụng thụt lề để hiển thị cấu trúc mã của bạn.

Đó là nó.

Đối với tôi, ưu điểm chính của một định dạng phổ biến được áp dụng tự động là nó giúp theo dõi thay đổi & đánh giá mã của chúng tôi. git (và hầu hết các công cụ kiểm soát nguồn khác) có thể hiển thị các khác biệt của các phiên bản trước của tệp. Bằng cách thực thi một kiểu chung, nó giảm thiểu các ưu tiên khác nhau của lập trình viên.

Hướng dẫn kiểu cũng cho phép phân tích mã theo chương trình dễ dàng hơn cho các mục đích phân tích khác nhau.

Google đã xuất bản một bài báo về điều này có tên là "Tìm kiếm nợ xây dựng: Kinh nghiệm quản lý nợ kỹ thuật tại Google" .

Đó là ngôn ngữ không phải là mã. Con người chúng ta có hơn 6000 ngôn ngữ nên chúng tôi dịch chúng. Vì vậy, nếu bạn muốn "mã" của mình giao tiếp, bạn sẽ phải điều chỉnh. Bạn thấy người dùng chúng tôi phải thay đổi định dạng dữ liệu của mình để chúng tôi không mất dữ liệu.

Tôi sẽ nói là không. Một cấu trúc / định dạng mã phổ biến giữa một nhóm chắc chắn là một điều tốt, nhưng tự động thực thi nó thì không. Điều này nên được thực hiện bởi con người, không phải bởi máy tính.

Vấn đề lớn nhất của tôi với khái niệm này là

1. Nếu tôi đang viết mã theo một định dạng và nó được tự động định dạng lại, thì có gì khuyến khích để thực sự học định dạng đó?
2. Theo điểm trước đó, nếu bạn không học định dạng, toàn bộ điểm tự động định dạng (để làm cho mã dễ đọc và sửa đổi hơn) sẽ bị mất hoàn toàn. Bạn vẫn phải dành thời gian để tìm ra định dạng khi bạn đang đọc mã vì bạn chưa học định dạng đó
3. Tôi nghĩ rằng sẽ là một kinh nghiệm chói tai khi một nhà phát triển viết một lớp học một ngày, đóng nó và trở lại vào ngày hôm sau để thấy nó hoàn toàn khác. Điều đó có nghĩa là không chỉ người khác phải học mã của bạn, bạn còn phải học mã của bạn.
4. Nó cũng có thể khuyến khích mã hóa lười biếng. Thay vì thúc đẩy nhà phát triển tìm hiểu định dạng, họ có thể viết ở bất kỳ định dạng nào dưới ánh mặt trời và nó sẽ tự động nhìn theo cách mà mọi người khác muốn. Điều này quay trở lại # 2 nơi bạn không học phong cách và vẫn không thể đọc chính xác.

Bây giờ, tôi có thể có khuynh hướng nói rằng chạy một định dạng tự động trên một dự án được gói gọn sẽ là một ý tưởng tốt. Điều này sẽ bắt đầu mọi dev trên cùng một chân cho dự án khi bạn đi sửa / thêm các tính năng sau này. Tuy nhiên, trong quá trình phát triển tích cực, tôi nghĩ đó là một lựa chọn rất kém.

Về cơ bản: Đặt trách nhiệm cho nhân viên tìm hiểu phong cách của công ty, đừng ép buộc mã của họ phải là thứ gì đó không phải.