Định dạng mã là một điều xấu khi sử dụng một VCS?

24

Tôi hầu như luôn định dạng mã của mình trước khi tôi cam kết đảm bảo nó được thực hiện đúng. Hầu hết nhóm của tôi không thực sự quan tâm và không luôn định dạng mã của họ đúng cách (những điều nhỏ không ảnh hưởng đến mã nhưng ảnh hưởng đến khả năng đọc khi cố gắng duy trì mã).

Gần đây tôi đã cài đặt các công cụ nguồn VS có tùy chọn "Định dạng lưu" và thực hiện thay đổi đối với tệp không được định dạng trước. VP phát triển chỉ đến với tôi và khiển trách tôi về định dạng vì nó xuất hiện trong công cụ hợp nhất vì gần như toàn bộ tệp đã thay đổi, thay vì chỉ một hoặc hai dòng (vì vậy anh ta không thể thấy chính xác những gì tôi đã sửa đổi) và nói với tôi để vô hiệu hóa định dạng lưu trong tương lai. Mặc dù tôi hiểu mối quan tâm đó, đôi khi tôi cảm thấy khó khăn khi sắp xếp mã không được định dạng và IMO nên được định dạng chính xác mọi lúc. Lưu ý rằng tôi không chỉ định dạng lại mọi thứ một cách bất chợt, mà khi tôi viết mã, tôi sẽ sử dụng công cụ quyền lực hoặc nhấn lệnh chính để định dạng văn bản để dễ đọc hơn và trong SVN, nó hiển thị dưới dạng một sửa đổi.

Vì vậy, tôi hỏi, luôn luôn định dạng mã thực sự là một điều xấu? Là mối quan tâm của anh ấy hợp lệ hơn là đảm bảo mã có thể đọc được?

code-formatting

— Allan Wight
nguồn

8

anh ấy đúng, vậy tại sao không bắt tất cả nhóm sử dụng công cụ lưu định dạng, sau đó tất cả bạn sẽ nhận được mã được định dạng độc đáo, dễ đọc và dễ xem các khác biệt.

— gbjbaanb

12

Hầu hết các công cụ so sánh tệp tốt đều có bộ lọc cho "sự khác biệt không quan trọng" hoặc "bỏ qua khoảng trắng". Một số, như Beyond So sánh, xuất xưởng với các bộ lọc dành riêng cho ngôn ngữ. Sử dụng nó để lợi thế của bạn nếu bạn có nó.

— Michael K

7

Định dạng của mã cũng quan trọng như những thay đổi đã được thực hiện. Khả năng đọc phải là một trong những ưu tiên cao nhất khi bạn ở trong một nhóm. VP của bạn nên biết điều đó và quan tâm đến nó.

— Edgar Gonzalez

@Edgar: +1. VP đang quá kén chọn. Khả năng đọc đầu tiên ... và một tùy chọn bỏ qua khoảng trắng có nghĩa là đây không phải là vấn đề lớn. Và nó cũng có nghĩa là có một vấn đề lớn hơn bởi vì phần còn lại của đội không quan tâm. VP nên quan tâm hơn về điều đó.

— quick_now

41

Trước hết, nhóm của bạn cần chọn một quy ước định dạng và gắn bó với nó. Bạn cần phải đi đến một thỏa thuận và yêu cầu mọi người tuân theo nó để bạn không có người đấu tranh về những thứ sẽ như thế nào. Đây không chỉ là một cái gì đó bạn tự làm.

Đối với câu hỏi thực sự của bạn. Mã định dạng không phải là một điều xấu. Điều gì là xấu là thực hiện các thay đổi định dạng chính trong cùng một cam kết như thay đổi mã. Khi nhóm của bạn đi đến thống nhất về cách mọi thứ nên được định dạng, hãy tạo một thông qua mã và định dạng mọi thứ. Kiểm tra xem trong chính nó. Thông báo cam kết sẽ làm rõ rằng các thay đổi chỉ là khoảng trắng và không hoạt động. Sau đó, khi bạn cần thực hiện các thay đổi chức năng, chúng nằm trong một cam kết khác để chúng có thể được nhìn thấy rõ ràng.

— unolysampler
nguồn

nó vẫn không hữu ích nếu bạn muốn so sánh các thay đổi từ một vài lần sửa đổi trước đây, nhưng nó tốt hơn thay đổi mã + thay đổi định dạng trong 1 lần. Tất nhiên, câu trả lời này cũng áp dụng cho tái cấu trúc.

— gbjbaanb

1

+1: Ngoài ra, thật tốt khi sử dụng một cái gì đó như Stylecop hoặc một số công cụ khác tự động định dạng và thực thi kiểu. Sau đó, đồng bộ hóa các cài đặt giữa tất cả các thành viên trong nhóm để định dạng phù hợp với mọi người và bạn không nhất thiết phải nhớ quy tắc định dạng "đúng" là gì.

— Ryan Hayes

3

Nếu OP bị khiển trách vì cố gắng định dạng một tài liệu, một cái gì đó cho tôi biết anh ta sẽ không thể đề xuất sử dụng StyleCop.

— Wayne Molina

3

@gbjbaanb: Vâng. Đây là lý do tại sao tốt nhất là đưa ra các loại quyết định khi bắt đầu. Dự án tôi đang thực hiện có các cài đặt định dạng Eclipse được kiểm tra vào kho lưu trữ để chúng tôi biết mọi người đều có cùng các cài đặt.

— unolysampler

1

@quickly_now: Đây là lý do tại sao chúng tôi có người quản lý có quyền phủ quyết. Nếu mọi người không thể đồng ý, họ có thể đưa ra quyết định.

— unolysampler

29

Không, mã định dạng là rất quan trọng . Tuy nhiên, cam kết nên được thực hiện trong hai nhóm:

Thay đổi mỹ phẩm - bất cứ điều gì làm cho mã dễ đọc hơn.
Những thay đổi khác - mọi thứ khác ảnh hưởng đến mã.

Sử dụng thông điệp cam kết để biểu thị rằng chỉ mỹ phẩm đã được thay đổi. Chúng có thể dễ dàng bỏ qua khi tìm kiếm các sửa đổi quan trọng hơn.

— JK
nguồn

3

Ngoài ra, đó cũng là một cách thực hành tốt để quyết định một quy ước định dạng nhất định giữa nhóm của bạn. Đừng chỉ định dạng mã từ người khác mà không thảo luận về điều này trước.

— Steven Jeuris

Vâng .. Nhưng bạn biết đấy, đôi khi thật hấp dẫn khi định dạng thứ hỗn độn chết tiệt đó "trong khi bạn đang ở đó". Ngoài ra, cố gắng tách các thay đổi mỹ phẩm khỏi các thay đổi chức năng có thể là một nỗi đau nếu bạn sử dụng VS và nó định dạng một cái gì đó tự động. Ồ, và không ai sẽ nói rằng bạn đang thực hiện một số định dạng ngu ngốc trong khi bạn có Nhiệm vụ rất quan trọng phải làm bằng cách xem lịch sử cam kết

— Dyppl

10

Cả hai bạn đều có một điểm, nhưng cả hai bạn đều có thể có được những gì bạn muốn. Định dạng mã trước, chỉ kiểm tra thay đổi đó. Tiếp theo, thực hiện các thay đổi chức năng của bạn và kiểm tra xem đó là bước thứ hai.

— Peter ALLenWebb
nguồn

3

Tôi nghĩ rằng đây là giải pháp tốt nhất cho tình huống hiện tại của bạn, nhưng bạn nên nói về nó với nhóm của bạn. Tuy nhiên, bạn có một vấn đề lớn hơn, đó là thiếu một tiêu chuẩn mã hóa.

— Thomas Owens

2

Đã đồng ý. Tôi tự hỏi liệu môi trường của OP có phải là một trong những nơi cao bồi hay không, nơi các tiêu chuẩn được tránh khỏi để "giải quyết mọi thứ nhanh chóng".

— Wayne Molina

4

Tôi cũng là một người chọn định dạng nit, vì vậy đây là một vài mẹo:

Bước đầu tiên bắt buộc: khiến nhóm đồng ý về một số tiêu chuẩn định dạng cơ bản, chẳng hạn như tab so với dấu cách, vị trí dấu ngoặc, kiểu nhận xét, v.v ... Bây giờ các thay đổi định dạng của bạn sẽ không hoàn toàn gây ngạc nhiên cho mọi người và bạn sẽ không bước trên bất kỳ ngón chân.
Làm sạch định dạng chỉ xung quanh mã bạn thay đổi. Nếu bạn thay đổi chỉ một chức năng, thì hãy dọn sạch chức năng đó. Ít nhất theo thời gian bạn sẽ có mã tìm kiếm tốt hơn.
Thực hiện đại tu định dạng chính như một cam kết riêng biệt, không có thay đổi mã nào khác. Bạn chỉ nên làm những việc này khi bạn ít muốn so sánh mã sau khi thay đổi trước khi thay đổi, vì việc so sánh qua một khác biệt như thế có thể gây khó chịu. Tôi thường làm công việc dọn dẹp như là điều đầu tiên trước khi phát triển chính về mã đó.
Có được một công cụ tìm khác biệt tốt có thể đánh dấu phụ thuộc vào ngôn ngữ của những thay đổi quan trọng và những thay đổi không đáng kể. Khác biệt yêu thích của tôi Ngoài Beyond So sánh các thay đổi mã thực tế trong một màu và khoảng trắng / nhận xét chỉ khác nhau ở một màu khác.

chỉnh sửa để biết thêm một mẹo:

Nó thay đổi ngôn ngữ hình thức thành ngôn ngữ, nhưng đối với hầu hết các thay đổi thực sự về mã hóa, bạn nên có thể so sánh các nhị phân được biên dịch trước và sau khi dọn dẹp chính để chắc chắn rằng bạn không làm hỏng nó.

— John
nguồn

Miễn là bạn không bao gồm các thẻ VC trong tệp nhị phân (hoặc thông tin xây dựng).

— Vatine

2

Bạn không nên định dạng lại và cam kết thay đổi mã của người khác trừ khi:

bạn là người quản lý đang cố gắng thiết lập các tiêu chuẩn mã hóa nhóm
người quản lý của bạn đã yêu cầu bạn dọn sạch mã để tuân thủ các tiêu chuẩn mã hóa nhóm
bạn đang dọn dẹp mã từ một nhà phát triển không còn trong nhóm của bạn để tuân thủ các tiêu chuẩn mã hóa nhóm.

Bạn sẽ chú ý trong mọi trường hợp tôi đề cập đến các tiêu chuẩn mã hóa nhóm. Tôi là một người tin tưởng mạnh mẽ vào các tiêu chuẩn mã hóa hợp lý, đã thỏa thuận cho nhóm. Nếu bạn có chúng, thì nhà phát triển ban đầu nên quay lại và dọn sạch mã của anh ấy hoặc cô ấy để tuân thủ các tiêu chuẩn của đội, bạn không nên làm điều đó sau lưng họ. Nếu bạn không có tiêu chuẩn (và bạn nên), thì bạn không nên sửa đổi mã của một thành viên khác trong nhóm để tuân thủ các triết lý của bạn, đặc biệt là sau lưng họ. Hãy nhớ rằng, bạn là một phần của một nhóm và trong khi các tiêu chuẩn mã hóa là quan trọng, thì sự tin tưởng và tôn trọng giữa các thành viên trong nhóm cũng vậy.

— cdkMoose
nguồn

"Đằng sau lưng": điều này quay trở lại các vấn đề tâm lý về quyền sở hữu mã (hoặc chiến tranh sân cỏ phát triển).

— rwong

2

"Mã của người khác" là một cách thú vị để nói về nó. Tôi làm việc trên sản phẩm của công ty tôi, được biên soạn từ mã công ty tôi sở hữu, mà các thành viên trong nhóm của tôi và tôi làm việc. Nó không phải là đằng sau lưng của họ trong bất kỳ cách nào để sửa nó theo các tiêu chuẩn trong khi làm việc với nó. Tuy nhiên, tôi đồng ý rằng giải pháp lý tưởng là làm cho nhà phát triển ban đầu làm sạch nó theo tiêu chuẩn.

— Caleb Huitt - cjhuitt

@Caleb: Khó khăn nếu họ từ chối thẳng thừng.

— quick_now

Theo "mã của người khác" Tôi không có nghĩa là quyền sở hữu, tôi có nghĩa là một cái gì đó họ đã viết và tin rằng họ vẫn có trách nhiệm hỗ trợ. Trong trường hợp không có tiêu chuẩn mã hóa, nếu tôi triển khai một lớp có 1.000 dòng mã và bạn thay đổi thành 2 dòng để sửa một số hành vi và định dạng lại toàn bộ tệp, tôi sẽ rất ngạc nhiên khi mở tệp. Là thành viên của một đội, chúng tôi không nên làm điều đó với nhau. Nếu bạn kiểm tra tệp đó với một định dạng lại đầy đủ và thậm chí không cho tôi ngẩng cao đầu, điều đó không thân thiện với đội ngũ.

— cdkMoose

Trong cuộc thảo luận ban đầu của OP, tôi đọc rằng đó là một môi trường không có tiêu chuẩn mã hóa (hoặc không được thi hành tốt), đó là lý do tại sao tôi trả lời như vậy. Trong môi trường đó, một nhà phát triển không nên áp đặt tiêu chuẩn của mình lên người khác.

— cdkMoose