Tôi ghét một trong những tiêu chuẩn mã hóa của chúng tôi và nó khiến tôi phát điên, làm thế nào để xử lý nó? [đóng cửa]


18

Disclaimer : Không cường điệu như tiêu đề cho thấy, nhưng nó vẫn khiến tôi không thoải mái. Tôi sẽ thể hiện một cách trung thực, vì vậy hãy mang nó với một hạt muối. Chỉ cần giả vờ rằng tôi đang nói về rằng tiêu chuẩn mã hóa mà bạn không thích làm việc với.

Chỉnh sửa : Thực tế là tôi không thích nó, không có nghĩa là tôi không sử dụng nó hoặc thi hành nó.


Tôi quyết định đặt câu hỏi này với tinh thần làm thế nào để vượt qua một tiêu chuẩn mà bạn không thích, không được giúp đỡ về cách tranh luận tốt hơn về cách có thể thay đổi (mặc dù mọi ý kiến ​​liên quan đến phần cuối cùng này đều được đánh giá cao). Bên cạnh đó, tôi làm việc trong một công ty lớn và việc thay đổi một thứ đã tồn tại quá lâu và vấn đề đó rất ít xảy ra.

Tiêu chuẩn là tiêu chuẩn mở-xoăn-brace-on-dành riêng cho dòng:

somefunction()
{
    //...
}

Thay vì * rõ ràng vượt trội * (lưu ý giai điệu đùa / bực bội):

somefunction() {
    //...
}

Lập luận cá nhân của tôi chống lại tiêu chuẩn:

  • Nó nở mã : thêm dòng không cần thiết
  • Khó gõ hơn : mặc dù có lẽ đây chỉ là tôi đang vật lộn với tiêu chuẩn, tôi biết thêm một lần nhấn phím không tệ đến thế.
  • Không dễ đọc hơn : Tôi bắt đầu đọc một khai báo hàm, nếu câu lệnh hoặc bất kỳ câu lệnh sắp xếp phạm vi nào khác và tôi đã không phải tìm kiếm một dấu ngoặc mở. Các khối lồng nhau với tiêu chuẩn này chỉ khiến tôi tức giận vì một số lý do.
  • Được sử dụng bởi những người đến từ nền tảng Microsoft IDE : Tôi nghĩ rằng nên có một lý do tranh luận (hoặc hơn) đằng sau một tiêu chuẩn, không chỉ đưa nó vào mô hình.

Lập luận của họ (và cách tôi phản ứng nội bộ với họ):

  • Dễ đọc hơn vì bạn có thể thấy các khối bắt đầu và kết thúc ngay lập tức : Tôi không thể hiểu điều này, khối nào tốt nếu bạn không biết nó thuộc sở hữu của cái gì, vì vậy sau đó bạn phải đọc ngược.
  • Tôi đã sử dụng nó trong Microsoft IDE và tôi thích nó : Uhh ... ok?
  • Đó là trong tiêu chuẩn : * cringes *

Tôi có phải là người duy nhất đấu tranh với lập trường có quan điểm chống lại một tiêu chuẩn cụ thể không?, Bạn đã vượt qua những điều này như thế nào?, Ý kiến ​​của bạn về tiêu chuẩn đặc biệt này là gì (chỉ để cho vui)?


6
bạn sử dụng tiêu chuẩn mà bạn "ghét" trong bao lâu? và bạn có sử dụng các tiêu chuẩn khác "song song" không? Ý tôi là, nó có thể chỉ là vấn đề làm quen với nó? Phải thừa nhận tôi từng ghét tiêu chuẩn tương tự, nhưng sau khoảng một năm viết riêng theo cách đó thì sự ghét bỏ này đã biến mất hoàn toàn
gnat

54
Bạn đang bỏ qua khoảng trắng được yêu cầu rõ ràng giữa phần cuối của khai báo hàm và dấu ngoặc nhọn! Bạn phải đốt!
pap

5
Sống với nó. Đó là một vấn đề thực sự rất nhỏ. Hãy hạnh phúc vì đó là điều duy nhất làm phiền bạn. Nếu bạn thay đổi ngôn ngữ, bạn cũng có thể điều chỉnh theo phong cách mới. Vì vậy, làm việc trong một vài tuần với nó sẽ khắc phục cảm giác đó là "sai".
schlingel

8
Used by people who come from a Microsoft IDE backgroundĐây không phải là một thứ của Microsoft, ví dụ Linux Kernel và K & R sử dụng cùng một kiểu.
Lucas

5
Nếu bạn dành tất cả năng lượng của mình để nổi giận về những chuyện nhỏ nhặt, bạn sẽ không còn bất kỳ điều gì cho những điều thực sự quan trọng.
Blrfl

Câu trả lời:


47

Nếu bạn muốn vượt qua điều này - đã có một trích dẫn của Torvalds:

Lập trình viên xấu lo lắng về mã. Các lập trình viên giỏi lo lắng về cấu trúc dữ liệu và các mối quan hệ của họ.

Bây giờ hãy xem xét, nơi nào đặt các lập trình viên lo lắng về một điều nhỏ như kiểu giằng được thi hành theo tiêu chuẩn mã của họ? Có phải codebase của bạn rất nguyên sơ đến nỗi việc niềng răng là vấn đề duy nhất đáng để bạn tranh luận?


2
Tôi hoàn toàn đồng ý. Nếu bạn đã giải quyết tất cả các vấn đề khác và quyết định nơi đặt các lọn tóc là điều quan trọng nhất còn lại, thì bạn đang làm tốt hơn mọi dự án phần mềm khác ngoài kia.

4
Có phải codebase của bạn rất nguyên sơ đến nỗi việc niềng răng là vấn đề duy nhất đáng để bạn tranh luận? - Đây sẽ là một câu hỏi tu từ - một codebase như vậy chưa từng tồn tại trong lịch sử!
MattDavey

12
Tôi muốn thêm rằng Linus trở nên điên rồ
Giles Roberts

Đó là bởi vì anh ấy đã nhận xét về thực tế rằng bạn đang tham gia vào một dự án, bạn tôn trọng hướng dẫn về phong cách của dự án và gửi đề xuất để thay đổi nó ... nếu không thì hãy tuân theo phong cách của họ!
Rudolf Olah

1
@GilesRoberts: Linus trở nên vô nghĩa nếu bạn định dạng tin nhắn git commit "không chính xác", vì nó không hoạt động với quy trình xem xét đã thiết lập. Một hoạt động tốt cho dự án trong 20 năm và liên quan đến hàng trăm người. Một số quy tắc quy trình quan trọng hơn nhiều so với quy tắc định dạng mã.
Jan Hudec

66

Một số người thích nó theo cách của bạn và những người khác thì không. Dù thế nào thì ai đó cũng sẽ khó chịu. Đây chỉ là lượt của bạn lần này. Mút nó và tiếp tục với công việc.


5
Tôi nghĩ anh ấy hỏi làm thế nào anh ấy nên vượt qua nó. Đó thực sự là một câu hỏi rất khác nhau.
Zachary Yates

18
Không tuân theo tiêu chuẩn sẽ tạo ra một vấn đề tồi tệ hơn, và làm phiền mọi người . "Suck it up" thực sự!
Frank Shearar

2
Tôi đồng ý. Bạn chỉ cần đối phó với nó.
Cody

3
Thành thật mà nói, điều đó cũng làm tôi thất vọng, nhưng thật không may, "hút nó đi" là câu trả lời đúng.
Sulthan

27

Là tiêu chuẩn của đội được ghi lại? Nếu có, có bất kỳ lý do trong hướng dẫn phong cách? Thành thật mà nói, tôi đã phải hút nó rất nhiều lần và hoàn thành công việc thực sự. Có những vấn đề tồi tệ hơn để có, nhưng tôi cảm thấy bạn - nó vẫn được xếp hạng (nhân tiện, tôi đồng ý với bạn về phong cách).

Điều gì đã giúp tôi vượt qua nó:

  1. Nhận ra rằng có những lợi ích thực sự cho một phong cách duy nhất (bất kể đó là gì). Hoặc ít nhất là một loạt người nghĩ như vậy .
  2. Chính xác những gì bạn vừa làm, viết ra lý do tại sao nó cảm thấy sai, để bạn có thể đưa ra lập luận tốt trong tương lai.
  3. Sử dụng một công cụ tạo kiểu cho chúa , nó sẽ tiết kiệm sự tỉnh táo của bạn. Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , v.v ... thậm chí Visual Studio sẽ làm điều đó cho bạn .
  4. Kick ass vào dự án này và sẵn sàng cho lần tiếp theo khi bạn có thể thiết lập các tiêu chuẩn.

7
+1 cho (3), điểm thưởng nếu bạn thiết lập nó dưới dạng móc sau kéo / đẩy trước cho SCM bạn đang bật.
Martin Green

1
Các công cụ tạo kiểu làm cho vấn đề này biến mất và khiến mọi người bỏ tiền vào miệng. Nếu bạn thực sự nới lỏng các kiểu niềng răng theo một cách riêng, thì bạn hãy thay đổi cấu hình kiểu dáng của mình để làm cho nó ấm áp và ấm cúng cho chính mình. Nếu không, ngậm miệng có thể nhận được mã hóa.
Calphool

16

Sự vượt trội của một quy ước so với quy ước khác là * rõ ràng tùy ý * .

Các vấn đề về khả năng đọc mà bạn gặp phải, hoặc các đồng đội của bạn sẽ phải đối mặt với tiêu chuẩn của bạn, chỉ là một sự kháng cự tâm lý để thay đổi.

Đối số dễ đọc mục tiêu ủng hộ * tính nhất quán * trên toàn bộ cơ sở mã.


"Chỉ" một sự kháng cự tâm lý để thay đổi? Sức đề kháng tâm lý để thay đổi có thể khá lớn.
Giles Roberts

8

Nghĩ lại một thời gian khi bạn chắc chắn rằng bạn đã đúng về điều gì đó và trong một khoảng thời gian nhận ra rằng bạn đã sai, hoặc ít nhất là bạn đã phản ứng thái quá tất cả những năm trước. Xem xét khả năng bạn có thể lại sai và đưa ra tiêu chuẩn mã hóa mới hoặc thời gian xử lý để thuyết phục bạn.

Các tiêu chuẩn của riêng tôi nổi giận khi tôi còn khá mới đối với tiền mã hóa (giả sử năm năm trong sự nghiệp của tôi) là liệu số nhận dạng đa từ có nên WrittenLikeThishay không written_like_this. Tôi thậm chí sẽ không nói tôi đã chọn ai, nhưng vấn đề là sau một thời gian tôi đã đổi phe và sau một thời gian nữa tôi cũng không quan tâm.


Vâng, tôi cũng bị giằng xé giữa like_this và like This. Gần đây tôi đang nghiêng về kiểu chữ thường, nó đơn giản rõ ràng hơn để đọc.
doug65536

1
Tất nhiên, bây giờ tôi bị mắc kẹt với like This trong một số dự án. Ồ, quy ước đặt tên không quan trọng lắm trong sơ đồ lớn của mọi thứ.
doug65536

1
Chính xác. Nó không thành vấn đề trong một chút về việc mở niềng răng. Việc bạn viết MultiWordIdentifier hay multi_word_identifier không thành vấn đề. Dù tiêu chuẩn của công ty bạn là gì, hãy tuân theo nó, và trong một vài tháng, bạn sẽ khó nhớ được bạn từng muốn làm theo cách khác.
Carson63000

8

Sự khác biệt tiêu chuẩn mà bạn mô tả với các dấu ngoặc nhọn phần lớn là tùy ý. Cả hai cách đều tốt như nhau và đối với một công ty, miễn là mọi người đều làm như vậy thì tất cả đều tốt.

"Cấp trên rõ ràng" mà bạn đang nói đến là loại ưu việt mà mọi người nói đến khi họ nói về những điều "họ đã quen".

Bạn sẽ quen với nó sớm thôi và trong một năm nữa, cách khác sẽ "rõ ràng vượt trội".

Vì vậy, trong ngắn hạn: đối phó với nó.


một câu trả lời rõ ràng vượt trội
Mawg nói rằng phục hồi Monica

5

Chủ đề đặc biệt này tương đương với Cuộc chiến tôn giáo giữa những người thích phong cách này hơn phong cách khác. Rất ít người mơ hồ ...

Cuối cùng, không đúng và cũng không sai.

Hướng dẫn về phong cách và tiêu chuẩn mã hóa tồn tại vì một số lý do - và một khía cạnh quan trọng là đảm bảo tính đồng nhất của bố cục, nhằm mục đích giảm số lượng lỗi rõ ràng và cải thiện khả năng bảo trì.

Tôi có phải là người duy nhất đấu tranh với lập trường chống lại một tiêu chuẩn cụ thể không?

Câu trả lời ngắn gọn là "Không", bạn không phải là người duy nhất. Nhưng có nhiều điều quan trọng hơn để lo lắng. Ngay cả trong các tiêu chuẩn mà người ta có đầu vào, sẽ luôn có sự thỏa hiệp - chứng kiến ​​một số khía cạnh đã biến nó thành C99 và C12 không có ý nghĩa với tôi.

Ngay cả MISRA-C (mà tôi có ảnh hưởng trực tiếp) cũng chứa các mục mà cá nhân tôi không đồng ý - nhưng tôi có thể hiểu tại sao người khác cảm thấy sự biện minh cho.

Làm thế nào bạn có được những điều này?

Và trong đó có câu trả lời - thay vì tập trung vào lý do tại sao bạn không thích cá nhân, hãy thử và hiểu lý do tại sao người / người đồng ý lại làm như vậy.

Các quy tắc thường được đưa ra (trong một cánh cửa ổn định sau khi ngựa đã chốt kiểu) để giải quyết vấn đề trước đó. Và nếu quy tắc vẫn vô lý, hãy nói chuyện với chủ sở hữu tiêu chuẩn và thử và "giáo dục" họ.


4

Tôi nghĩ rằng bạn chỉ cần có được với nó. Tôi sẽ cố gắng giải quyết các ghi chú của bạn với ý kiến ​​của riêng tôi:

  • Mã Bloats

    Một dòng mã bổ sung hoàn toàn không phải là mã đầy đủ, trừ khi bạn đang viết 100 phương thức trong một lớp, điều đó sẽ thêm hàng trăm dòng bổ sung. Sau đó, một lần nữa nếu bạn có hàng trăm phương thức trong một lớp, bạn có một vấn đề khác hoàn toàn.

  • Khó gõ hơn

    Tôi không thể không đồng ý với bạn nữa về điều này, bạn phải nhấn phím quay lại để đến dòng tiếp theo. Những gì về nó là khó khăn hơn để gõ?

  • Khó đọc hơn

    Tôi cảm thấy như mỗi dòng trong một đoạn mã nên có một chức năng cụ thể. Theo cách này, bạn sẽ cần xác định tên phương thức trong một dòng, sau đó là dấu ngoặc mở và đóng trên các dòng riêng biệt của chúng.

  • Được sử dụng bởi những người đến từ nền tảng MS IDE

    Ừ ..... được chứ?

Tóm lại, có vẻ như bạn đang lo lắng về việc trở thành một nhà phát triển .Net trái ngược với bất kỳ loại nhà phát triển nào khác như thể nó kém hơn bởi vì họ đã sử dụng một IDE mặc định theo tiêu chuẩn này.


1
-1 Tôi đồng ý về tất cả các điểm, nhưng tôi không nghĩ bất kỳ ý kiến ​​nào về từng điểm khác nhau là đặc biệt hữu ích.
Caleb

4

Tôi có phải là người duy nhất đấu tranh với lập trường chống lại một tiêu chuẩn cụ thể không?

Dĩ nhiên là không. Các cuộc họp để xác định các tiêu chuẩn mã hóa là khủng khiếp! Họ kéo dài hàng giờ và những người tham gia trở thành cá nhân đầu tư để có được sự yêu thích của riêng họ (và luôn luôn sai, ngoại trừ của tôi) các đặc điểm riêng được ghi trong tiêu chuẩn. Cuối cùng, không ai hài lòng với kết quả này. Nếu bất cứ điều gì có thể tồi tệ hơn cuộc họp tiêu chuẩn mã hóa, thì đó là cuộc họp xem xét mã chính thức trong vài tháng tuân theo quyết định của tiêu chuẩn: một số người cố gắng áp dụng tiêu chuẩn, trong khi những người khác (cố ý hoặc không) bỏ qua nó, và bạn nhận được hàng giờ phản hồi như: Trên các dòng 132, 142, 145, 181, 195 và 221 của SillyFileConverter.cpp bạn đặt dấu ngoặc mở trên cùng một dòng khi tiêu chuẩn mã hóa nói rõ rằng nó phải nằm trên dòng sau !

Làm thế nào bạn có được những điều này?

Theo cách riêng của họ, các cuộc họp giúp đỡ. Ngay cả khi bạn đồng cảm hoàn toàn với anh chàng rời khỏi niềng răng trên cùng một dòng với điều kiện, hoặc bất cứ điều gì, bạn vẫn sẽ trở nên khó chịu với anh ta vì đã lãng phí thời gian của bạn bằng cách không hút nó và làm theo tiêu chuẩn ngu ngốc. Nếu anh chàng là một người tò mò và làm điều tương tự lặp đi lặp lại, điều đó càng trở nên khó chịu hơn. Việc khó chịu với hành vi đó khiến cho việc viết theo phong cách dễ dàng hơn nhiều so với những gì bạn thích - rốt cuộc bạn chắc chắn không muốn trở thành anh chàng đó .

Ngay cả khi bạn không phải chịu các đánh giá mã chính thức liên tục, bạn vẫn có thể thử xem lại mã của riêng mình để tuân thủ tiêu chuẩn. Không quan trọng bạn nghĩ gì về tiêu chuẩn, bạn chỉ đang so sánh những gì bạn đã viết với những gì tiêu chuẩn nói. Nếu bạn tự dìm mình mỗi khi bạn không tuân thủ, điều đó có thể cung cấp một số phản hồi tiêu cực mà bạn cần để giúp bạn áp dụng tiêu chuẩn.


"Tham gia vào nỗ lực tiêu chuẩn hóa ngôn ngữ ... Có ý thức tốt để thoát khỏi nỗ lực tiêu chuẩn hóa ngôn ngữ càng nhanh càng tốt" - norvig.com/21-days.html
Beni Cherniavsky-Paskin

3

Với loại điều này, tôi nhớ Gulliver trong Lilliput. Người Lilliputian đã chiến đấu trong một cuộc chiến tranh để kết thúc việc mở một quả trứng luộc. (The endian bigian gốc, little endian combat).

Hãy coi đó là cơ hội để tự cười mình, họ không thực sự đến đủ trong kinh doanh.


2

Ví dụ cụ thể của bạn là không may vì đây là một ví dụ mà một số người sẽ đồng ý và một số thì không. Tôi không đồng ý với lập luận của bạn chống lại ví dụ và tôi chắc chắn nhiều người khác cũng vậy, giống như tôi chắc chắn nhiều người khác sẽ đồng ý với họ. Nó gần như khiến tôi nghĩ rằng câu hỏi nên được đóng lại vì nó quá chủ quan.

Tuy nhiên, câu hỏi về cách đối phó với một tiêu chuẩn mà bạn không đồng ý có thể dễ trả lời hơn. Tôi nghĩ rằng câu trả lời là nơi các hướng dẫn kiểu dáng tồn tại và được đồng ý và đã được sử dụng thì câu trả lời chỉ là để cười, chịu đựng và chỉ cần đối phó với nó. Xem xét rằng có sự nhất quán là quan trọng hơn. Nếu hướng dẫn không chính xác hoặc sai, có thể có một đối số để thay đổi nhưng đây là phong cách nên không có đối số thực sự ngoài sở thích cá nhân.

Tôi đến từ một nền tảng Java ban đầu nên theo tiêu chuẩn mà bạn đề cập. Sau đó tôi đã chuyển sang C ++ và C # nhiều hơn, nơi phong cách bạn ghét được sử dụng. Nhưng nó không có câu trả lời đúng hay sai. Điều quan trọng hơn là có một tiêu chuẩn theo sau bởi tất cả mọi người. Nếu một tiêu chuẩn mã hóa là phong cách như thế này và rõ ràng là không sai thì cố gắng tranh luận nó sẽ chỉ gây ra ma sát trong nhóm.


1
Như đã nêu trong câu hỏi, câu hỏi thực sự không phải là về tiêu chuẩn cụ thể, vì vậy đoạn đầu tiên của bạn không phải là nguyên bản.
Caleb

2

Một formatter + check in hook là một khởi đầu tốt. Nhưng nó không đủ, vì những gì bạn viết không quan trọng bằng những gì bạn nhìn chằm chằm cả ngày. Trong một số trường hợp, cách tiếp cận của chế độ Kính của Emacs - giữ các tệp theo kiểu của chúng nhưng hiển thị gần hơn với kiểu của bạn - rất hấp dẫn.

Kinh nghiệm của tôi với nó - đối mặt chính xác với vấn đề được viết ra, CamelCapsso với underscore_separated- là nó nhanh chóng trở nên khó chịu hơn là hữu ích, nhưng trong một vài tuần, nó đã giúp tôi chuyển sang chấp nhận phong cách của công ty một cách miễn cưỡng, cũng như cung cấp một lối thoát để giải tỏa cơn giận của tôi ("ah tôi ghét nó, hãy để tôi điều chỉnh lại cài đặt ... ở đó, ít nhất là tôi đã làm gì đó ") ;-)

Dù sao, chế độ Kính không xử lý vị trí nẹp, bạn có thể không sử dụng Emacs và không đọc mã riêng trong trình chỉnh sửa của mình :-(
Nhưng điểm cuối cùng cũng là một cơ hội - nếu bạn đọc mã hầu hết thời gian trong một công cụ riêng biệt, bạn có thể hack nó để chuyển đổi kiểu mà không phải lo lắng về tiếng ồn định dạng lại chuyến đi khứ hồi - bởi vì nó chỉ đọc! Cụ thể, nếu bạn đọc mã trong một số giao diện web, hãy sử dụng Greasemonkey.

Dưới đây là một số ý tưởng dễ dàng hơn để giảm thiểu nhẹ:

  • Chọn một phông chữ rộng hơn nhưng không quá cao để lấy lại các dòng màn hình bị mất.

    • Sử dụng toàn màn hình thường xuyên hơn, nếu có sẵn.
  • Thiết lập dấu ngoặc nhọn được tô sáng bằng màu sắc tinh tế (và phông chữ nhỏ hơn?), Làm cho chúng ít nhìn thấy hơn phần còn lại của mã. Lõm phải đủ để đọc, đặc biệt. với không gian trống từ {các dòng ...

  • Hãy chắc chắn rằng trình soạn thảo của bạn làm nổi bật khớp nối mở khi bạn kết thúc }- có thể giúp ích một chút khi mắt bạn đi sai chỗ theo bản năng.

  • Re "khó gõ" hơn: lấy một trình soạn thảo thực sự, định cấu hình nó để tự động mở một dòng mới khi bạn nhấn {.


0

Sống với nó.

Đây rõ ràng là mỹ phẩm và không thay đổi bất cứ điều gì về chất lượng của mã hoặc năng suất của bạn với tư cách là nhà phát triển. Không có gì đáng để bắt đầu một cuộc tranh cãi.

Đối với loại tiêu chuẩn mã hóa đó, tôi sẽ chọn tính nhất quán trên cơ sở mã và khả năng đọc đối với bất kỳ cách tiếp cận "tôn giáo" cụ thể nào (thậm chí có lý do) bất kỳ ngày nào.

Nghĩ về nó như một quyết định dân chủ của đa số các thành viên trong nhóm về một vấn đề không quá quan trọng có thể giúp bạn vượt qua nó.



-5

Chỉ cần đi trước và sử dụng phong cách bạn muốn. Sau đó sử dụng một số trình làm đẹp mã để thay đổi mã theo định dạng tiêu chuẩn hoặc ngay ứng dụng nhỏ của riêng bạn sẽ chuyển đổi mã từ kiểu của bạn sang kiểu chuẩn đã cho. Sử dụng chất làm đẹp trước khi kiểm tra mã.
Bạn cũng có thể làm ngược lại để thay đổi mã được kiểm tra từ định dạng chuẩn sang định dạng của bạn, khi bạn đang làm việc với nó.


2
-1 Điểm của câu hỏi là làm thế nào tôi có thể vượt qua điều này? , nhưng lời khuyên của bạn sôi nổi là đừng cố gắng vượt qua nó, hãy tiếp tục làm theo cách của bạn. Điều đó dường như không hữu ích. Điều đó cũng không thực tế lắm - sử dụng một Prettyprinter tạo ra khả năng thiệt hại tài sản thế chấp, tức là sau khi chuyển đổi sang định dạng ưa thích của bạn và quay lại, nhiều dòng có thể không hoàn toàn giống nhau ngay cả khi chúng có nghĩa chính xác như nhau. Điều đó tạo ra rất nhiều rắc rối cho những người nhìn qua các phiên bản khác nhau cố gắng tìm hiểu những gì thực sự thay đổi.
Caleb

@Caleb - Có thể trải nghiệm sử dụng beautifulprinter của bạn có thể khác. Chúng tôi đang sử dụng Atristic Style và không ai có khiếu nại về nó.
Manoj R

9
Bất kỳ sự phát triển phần mềm nghiêm trọng nào cũng sẽ sử dụng một hệ thống kiểm soát nguồn. Giới thiệu những khác biệt không quan trọng sẽ gây ra vấn đề và khiến mọi người xem các khác biệt khó chịu - hoặc tệ hơn, gây ra xung đột khi đăng ký.
doug65536
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.