Tiêu chuẩn mã hóa tồi tệ nhất bạn từng phải tuân theo? [đóng cửa]

Bạn đã bao giờ phải làm việc theo các tiêu chuẩn mã hóa rằng:

• Giảm đáng kể năng suất của bạn?
• Ban đầu được bao gồm vì lý do tốt nhưng được giữ lâu sau khi mối quan tâm ban đầu trở nên không liên quan?
• Đã ở trong một danh sách dài đến mức không thể nhớ hết tất cả?
• Làm bạn nghĩ rằng tác giả chỉ đang cố gắng để lại dấu ấn của họ hơn là khuyến khích thực hành mã hóa tốt?
• Bạn không biết tại sao chúng được bao gồm?

Nếu vậy, quy tắc yêu thích ít nhất của bạn là gì và tại sao?

Một số ví dụ ở đây

Điều này có thể xù một vài chiếc lông vũ, nhưng các tiêu chuẩn bắt buộc các bình luận khối templated ở đầu mỗi phương pháp luôn làm tôi khó chịu.

1) Chúng luôn bị lỗi thời vì chúng ở quá xa mã thực hiện công việc thực tế cần chú ý khi bạn cập nhật mọi thứ. Bình luận xấu tệ hơn là không có bình luận.

2) Họ thường chỉ lặp lại thông tin đã có sẵn công cụ kiểm soát nguồn, chỉ kém chính xác. Ví dụ: Sửa đổi lần cuối bởi, danh sách ngày / lý do sửa đổi.

Có một giáo sư đã từng yêu cầu chúng tôi có ít nhất một nhận xét cho mỗi dòng mã.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

Nó thật là nực cười.

Tiêu chuẩn mã hóa của công ty chúng tôi (C #) được yêu cầu sử dụng rộng rãi #REGIONs (đối với những người không biết, nó đánh dấu các khối mã nguồn sẽ được ghép vào một dòng trong Visual Studio). Kết quả là, bạn luôn mở một thứ có vẻ là một lớp có cấu trúc độc đáo, chỉ để tìm những đống rác được quét dưới những tấm thảm được xây dựng sâu của các công trình #REGION. Bạn thậm chí có các vùng xung quanh các dòng đơn, ví dụ: phải gấp ra một vùng LOG để tìm một khai báo của Logger. Tất nhiên, rất nhiều phương pháp được thêm vào sau khi một số khu vực được thực hiện, cũng được đặt trong phạm vi khu vực "sai". Kinh dị. Kinh dị.

Khu vực là một trong những tính năng tồi tệ nhất từng được thêm vào Visual Studio; nó khuyến khích cấu trúc bề mặt hơn là cấu trúc OO thực tế.

Ngày nay, tôi giết #REGIONs trong tầm nhìn.

Trong một công việc, chúng tôi buộc phải sử dụng một số dạng ký hiệu Hungary kỳ lạ trong cơ sở dữ liệu.

Tôi không thể nhớ chi tiết, nhưng từ bộ nhớ, mỗi tên trường phải chứa:

• Không có nguyên âm
• Tất cả chữ in hoa
• Tham chiếu đến bảng
• Một chỉ báo loại dữ liệu
• Độ dài dữ liệu
• Một chỉ số vô hiệu

Ví dụ: cột chứa tên của một người có thể được gọi là: PRSNFRSTNMVC30X(Bảng người, cột Tên, 30 ký tự, Không phải là số không)

Nhấn mạnh rằng tất cả các niềng răng được theo sau bởi nhận xét cho những gì niềng răng kết thúc:

ví dụ:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'nuff nói.

• Tên biến cục bộ đều là chữ thường không có dấu gạch dưới

Ví dụ thực tế: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

Thời báo New York có trọng lượng :

Không gian Word Word không nên được chấp nhận. Tiếng Hy Lạp cổ đại, bảng chữ cái đầu tiên có nguyên âm, có thể được giải mã mà không có không gian từ nếu bạn phát âm ra và không có chúng. [Hoài] Tiếng Latin cũng vậy, đã ngừng phân tách các từ vào thế kỷ thứ hai. Mất mát là khó hiểu, bởi vì mắt phải làm việc nhiều hơn để đọc văn bản không tách rời. Nhưng như nhà cổ sinh vật học Paul Saenger đã giải thích, thế giới cổ đại không mong muốn 'làm cho việc đọc trở nên dễ dàng và dễ dàng hơn.'

Tôi đã hỏi bởi các nhà lãnh đạo phần mềm của một công ty để làm " đơn giản, tái n đang dundant ". Chẳng hạn, việc thêm một tham số mới vào một hàm hiện có đã bị cấm. Thay vào đó, bạn phải nhân đôi chức năng, để nguyên bản gốc không bị ảnh hưởng để tránh hồi quy. Không có thử nghiệm chính thức của khóa học (lãng phí thời gian).

Chúng tôi cũng bị cấm sử dụng phần mềm hợp nhất; mỗi tệp chỉ có thể được sửa đổi bởi một lập trình viên tại một thời điểm. Phần mềm kiểm soát sửa đổi là khoa học viễn tưởng, tất nhiên.

Ngày hạnh phúc nhất trong cuộc đời tôi là khi anh ấy bị sa thải (xem xét rằng việc sa thải ai đó ở Ý là rất, rất khó khăn).

Tất cả các tương tác với cơ sở dữ liệu phải được thực hiện thông qua các thủ tục được lưu trữ . Nó có thể có ý nghĩa nếu chúng ta sống vào năm 1997 chứ không phải năm 2010.

Tôi chỉ nhận ra rằng điều này thực sự bao gồm tất cả các tiêu chí của câu hỏi ban đầu:

• Giảm đáng kể năng suất của bạn? KIỂM TRA. Vui lòng - chỉ cần sử dụng ORM .
• Ban đầu được bao gồm vì lý do tốt nhưng được giữ lâu sau khi mối quan tâm ban đầu trở nên không liên quan? KIỂM TRA. Người quản lý là nhà phát triển cho một máy chủ cơ sở dữ liệu 1000 năm trước và đưa tiêu chuẩn mã hóa này vào.
• Đã ở trong một danh sách dài đến mức không thể nhớ hết tất cả? KIỂM TRA. Điều này bao gồm 'càng nhiều logic nên được lưu trữ trong cơ sở dữ liệu càng tốt'.
• Làm bạn nghĩ rằng tác giả chỉ đang cố gắng để lại dấu ấn của họ hơn là khuyến khích thực hành mã hóa tốt? KIỂM TRA. Tiếp tục quay trở lại người quản lý là một nhà phát triển máy chủ cơ sở dữ liệu cũ.
• Bạn không biết tại sao chúng được bao gồm? KIỂM TRA.

Không được phép sử dụng STL hoặc các thư viện C ++ tiêu chuẩn khác vì CTO tin rằng 'chúng tôi' có thể làm điều đó tốt hơn và nhanh hơn. Ngay cả các cấu trúc cơ bản như danh sách và lớp chuỗi.

Ký hiệu Hungary

Mẫu được trích từ " Charles Simonyi khám phá quy ước đặt tên ký hiệu Hungary " trên MSDN.

1 #incolee làng sy.h
2 bên ngoài int * rgwDic;
3 bên ngoài int bsyMac;
4 cấu trúc SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 cấu trúc SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 dấu không dấu wHash = 0;
13 pch = sz;
14 trong khi (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 cho (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 trong khi (* pch == * szSy ++)
24 {
25 nếu (* pch ++ == 0)
26 trở về (psy);
27}
28}
29 cwSz = 0;
30 nếu (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 Không ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 trở lại (psy);
36}

Tôi đã từng làm việc trong một dự án trong đó trưởng dự án bắt buộc rằng mọi biến số - MỌI biến - đều có tiền tố là "v". Vì vậy, vCount, vFirstName, vIsWarcill, v.v.

Tại sao? "Bởi vì chúng tôi đang làm việc trong VBScript và mọi thứ đều là Biến thể".

WTF.

Hầu như quên mất điều này:

Trích dẫn từ một người quản lý:

Không sửa chữa hoặc ghi lại bất kỳ lỗi nào của các vấn đề bạn tìm thấy trong mã của riêng bạn. Khách hàng sẽ trả tiền cho chúng tôi để xác định và sửa chữa chúng trong vài năm tới.

Điều này không dành cho phần mềm tiêu dùng, nhưng tùy chỉnh cho một tổ chức lớn. Không cần phải nói, khách hàng đã trả tiền trong nhiều năm sau đó. Có thể có vẻ tầm thường, nhưng cố gắng bỏ qua các lỗi khó hơn tìm thấy chúng.

Nhận xét XML được thực thi trên tất cả các phương thức, hằng, enum và thuộc tính không riêng tư.

Nó đã dẫn đến một số mã khá lộn xộn, đặc biệt là vì kết quả cuối cùng là mọi người chỉ cần nhấn /// để tạo một bình luận trống cho mọi thứ hoặc cài đặt GhostDoc và thêm nó vào các bình luận được tạo tự động:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[Chỉnh sửa] Lý do tôi đề cập đến điều này như một tiêu chuẩn lố bịch không phải vì tôi nghĩ các bình luận phương pháp là ngu ngốc mà vì chất lượng của các bình luận này không được thực thi theo bất kỳ cách nào và dẫn đến việc tạo ra rất nhiều sự lộn xộn trong các tệp mã . Có nhiều cách tốt hơn để tạo các tài liệu mã có ý nghĩa hơn là yêu cầu xây dựng "phải có một bình luận".

Không thực sự là một tiêu chuẩn mã hóa, nhưng chúng tôi đã có một tệp trong kiểm soát nguồn được gọi là 'changelog.txt'

Mỗi lần bạn thực hiện đăng ký, bạn phải tự thêm một mục vào tệp này. Mục nhập này là số sửa đổi lật đổ và nhận xét đăng ký của bạn.

Khi CTO mới bắt đầu và ai đó nói với anh điều này, anh đã nhanh chóng đưa ra quyết định điều hành và nói: "Chúng tôi sẽ không làm điều này nữa" và xóa tập tin. Điều này đã diễn ra trong nhiều năm.

Một số nơi tôi từng làm việc khăng khăng đòi bình luận về mã không được sử dụng hoặc không dùng nữa thay vì xóa nó. Thay vì tin tưởng vào VCS cho lịch sử, v.v., nó được duy trì một cách đau đớn trong các tệp thông qua mã nhận xét.

Vấn đề lớn tôi tìm thấy với điều này là bạn thường không biết tại sao mã được nhận xét. Có phải bởi vì một số nhà phát triển đã tích cực thực hiện các thay đổi và muốn giữ nó xung quanh để tham khảo hoặc không còn cần thiết nữa?

Tiêu chuẩn mã hóa tồi tệ nhất tôi từng tham gia là các cơ sở mã không có gì cả. Tôi thà tuân theo một tiêu chuẩn mã hóa mà tôi hoàn toàn không đồng ý hơn là làm việc trong các cơ sở mã nơi không có gì cả. Nó làm cho nó khó khăn hơn nhiều để tìm hiểu các phần mới của cơ sở mã.

Buộc nhận xét nội tuyến để kiểm soát phiên bản là về tiêu chuẩn mã hóa vô nghĩa nhất mà tôi bỏ qua.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

Oracle DBA khăng khăng đòi sử dụng đúng khoảng trắng trong khi 'duy trì' cơ sở dữ liệu với bảng có nhiều tranh chấp có hơn 200 trường và 40 trình kích hoạt đến gần.

Tôi đã thực hiện đánh giá mã trên một dự án được dẫn đầu bởi bộ đếm thời gian đầu tiên của C ++, người quyết định rằng tất cả các hàm thành viên của lớp nên được thêm tiền tố với tên lớp và mức độ hiển thị:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Được yêu cầu thụt lề tất cả mã theo bốn khoảng trắng;)

Tôi đã có một công việc cách đây nhiều năm, nơi tất cả các mã của chúng tôi phải được căn trái - không thụt lề. Anh chàng đưa ra chính sách đó không thích phải cuộn qua lại theo chiều ngang khi xem những dòng mã dài, đánh đồng nó chơi bóng bàn bằng mắt.

Đây là một ví dụ về việc không có các tiêu chuẩn mã hóa có thể gây tổn thương.

Một nhà thầu làm việc tại một ngân hàng lớn khẳng định rằng tuân theo các tiêu chuẩn là tốt nhất từ ​​trước đến nay. Ứng dụng này được viết bằng dBase / Clipper mà anh ấy là nhà phát triển duy nhất và tất nhiên anh ấy đã đưa ra tiêu chuẩn.

• Tất cả mọi thứ là trong trường hợp trên. Ý tôi là tất cả mọi thứ, kể cả những bình luận hiếm hoi anh ấy đưa ra.
• Không thụt.
• Đặt tên biến là một cái gì đó dọc theo dòng của APRGNAME. A = phạm vi của biến, ví dụ P cho công khai, PRG = ba ký tự đầu tiên của tệp nguồn đã tạo biến, NAME = tên biến trong 6 ký tự còn lại mà dBase / Clipper cho phép.
• 4 dòng đầu tiên và 4 dòng cuối của mã nguồn dài 80 *. Tại sao? Vì vậy, anh ta có thể nghe thấy máy in ma trận điểm bắt đầu và kết thúc việc in một tập tin. Bộ nhớ là toàn bộ chương trình được in qua máy tính lớn hàng tuần, 20.000 trang.
• Tôi chắc chắn rằng có nhiều hơn nữa tôi đã xoay sở từ bộ não của mình.

Tôi là một lập trình viên tự học rất mới ở giai đoạn đó nhưng biết đủ để không nghe nhà khoa học điên và rời khỏi đó trước khi tôi yêu cầu tiếp quản dự án.

Và vâng, chúng tôi đã nói với ban quản lý rằng những thực tiễn này tệ đến mức nào nhưng luôn có thông thường "đã trả cho nhà thầu này đồng đô la hàng đầu, anh ta phải biết anh ta đang nói về điều gì".

Một vụ nổ nữa từ quá khứ của tôi.

Trích dẫn từ chủ sở hữu công ty:

Sẽ không có mã được viết bằng các ngôn ngữ diễn giải vì tôi đã mất 25 triệu trong dự án {expletive} được viết bằng Java.

Dự án Java là một hệ thống giao dịch chứng khoán được thiết kế để xử lý vài chục cổ phiếu, hiện đang được sử dụng để xử lý hàng ngàn. Thay vì giải quyết các lỗi thiết kế hoặc phần cứng kém, toàn bộ công ty đã buộc phải chuyển đổi tất cả các ứng dụng không phải C / C ++ sang C / C ++, và tất cả sự phát triển mới phải có trong C / C ++. Các ngôn ngữ diễn giải có nghĩa là bất cứ thứ gì không được biên dịch và chủ sở hữu chỉ coi Trình biên dịch, C và C ++ được biên dịch.

Đối với một công ty 800 người, trong đó phần lớn mã là Java và Perl, điều này có nghĩa là toàn bộ công ty đã dành phần lớn thời gian của họ trong vài năm tiếp theo để viết lại mã hoàn toàn tốt trong C / C ++.

Buồn cười thay, khoảng hai mươi năm trước fiasco này, tôi đã ở một công ty khác, trong đó lãnh đạo công nghệ quyết định rằng logic sắp xếp của chúng tôi (đó là Bubble Sort) cần được mã hóa lại trong trình biên dịch thay vì được thay thế bởi Quick Sort vì - Thuật toán thực hiện không cải thiện hiệu suất. Cách duy nhất để cải thiện hiệu suất là viết lại logic tương tự trong trình biên dịch chương trình.

Trong cả hai trường hợp, tôi đã rời đi ngay sau khi các mệnh lệnh đi xuống.

Giống như nhiều lập trình viên (nhưng không đủ), tôi ghét trang trí mã. Nó làm tôi bực mình khi tôi phải sử dụng tiền tố ký hiệu đô la ($) cho tên biến hoặc dấu gạch dưới cho các biến riêng tư, ngay cả khi không có getters / setters. Nếu bạn cần trang trí mã của bạn để hiểu nó, thì bạn cần phải thoát khỏi địa ngục!

Tôi đã làm việc với một hệ thống web trong một thời gian mà tất cả các tham số được truyền phải được đặt tên là P1, P2, P3, v.v. Không có cơ hội nào để biết chúng ở đâu mà không có tài liệu mở rộng.

Ngoài ra - mặc dù không hoàn toàn là một tiêu chuẩn mã hóa - trong cùng một hệ thống, mỗi tệp duy nhất được đặt tên là xyz0001.ext, xyz0002.ext, xyz0003.ext, v.v. - trong đó xyz là mã cho chính ứng dụng.

Đây là một thời gian dài trước đây - chính xác là năm 1976. Sếp của tôi chưa bao giờ nghe về Edsger Dijkstra hoặc đọc một vấn đề về CACM, nhưng anh ta đã nghe một tin đồn từ đâu đó rằng "GOTO là xấu", vì vậy chúng tôi không được phép sử dụng GOTO trong các chương trình COBOL của chúng tôi. Đây là trước khi COBOL thêm "end if", vì vậy tại thời điểm đó, nó chỉ có hai và một nửa trong ba cấu trúc điều khiển cổ điển (chuỗi, nếu / sau đó / khác, thực hiện (tức là làm trong khi)). Anh ta miễn cưỡng cho phép GOTO trong các chương trình Cơ bản của chúng tôi và hướng dẫn chi nhánh trong các chương trình ngôn ngữ Trình biên dịch của chúng tôi.

Xin lỗi vì đây là một loại câu chuyện "bạn phải ở đó". Theo tôi biết, mọi ngôn ngữ được phát minh từ năm 1976 đều có cấu trúc kiểm soát đầy đủ để bạn không bao giờ cần sử dụng GOTO. Nhưng vấn đề là, ông chủ không bao giờ biết TẠI SAO GOTO bị coi là có hại, hay ngôn ngữ nào là rối loạn ở trẻ sơ sinh và đó là căn bệnh gây tử vong.

Tôi đã làm việc trong một dự án là kiến ​​trúc sư trưởng yêu cầu viết mã rõ ràng. Một trong những ví dụ tồi tệ nhất mà tôi tìm thấy trong mã (và anh ấy vui vẻ chấp thuận) là như sau.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Ngay cả ReSharper cũng nói với bạn điều này là sai!

Ở công việc cuối cùng của tôi, "tiêu chuẩn" sẽ là một thuật ngữ rất mạnh mẽ cho những gì tôi đã được đưa ra bởi người đã thuê tôi. Lập trình trang web trong ColdFusion và SQL, tôi đã được cung cấp các yêu cầu mã hóa như:

• Đừng sử dụng bao gồm. Tôi thích một trang lớn
• Luôn phân tách các từ trong tên biến và tên cột với dấu gạch dưới (ngoại trừ isactive, Firstname, v.v.)
• Không bao giờ sử dụng chữ viết tắt - luôn luôn viết tên đầu tiên (anh ấy thường xuyên viết tên và vv)
• Không sử dụng các tên khó hiểu (như số tiền_chargeed và Charge_amount, các số đo khác nhau nhưng có liên quan)
• Đừng sử dụng DIV và sử dụng CSS tối thiểu - thay vào đó hãy sử dụng các bảng lồng nhau (tôi đã tìm thấy một số sáu lớp sâu, một lần).
• Đừng lưu trữ bất kỳ truy vấn nào. Không bao giờ.
• Sẽ sử dụng một biến trên nhiều trang? Phạm vi ứng dụng.
• Mỗi trang là một khối thử / bắt riêng của nó. Chúng tôi không cần / muốn xử lý lỗi toàn cầu.

Tôi bắt đầu thay đổi những thứ này ngay khi anh ấy nghỉ việc.

Trong cuộc đời làm lập trình viên C ++ của tôi, hai "quy tắc" thực sự khó chịu đã được thi hành:

1. "Chúng tôi không thể sử dụng STL, vì VC ++ 4.1 không hỗ trợ nó (và chúng tôi không thể chuyển sang VC ++ 6.0 tại thời điểm này)."
2. "Đừng không sử dụng Sắp xếp nhanh, bởi vì nó có thể là O (n ^ 2) trong trường hợp xấu; sử dụng thực hiện này của thuật toán sắp xếp vun đống I (tên của lãnh đạo dự án xóa) đã viết như một sinh viên."

Tôi buộc phải có tài liệu XML cho tất cả các lớp và thành viên lớp. Bao gồm cả tư nhân. Tôi được bảo đảm sử dụng các bình luận ghostdoc mặc định.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}