Đã từng có những lý do rất tốt để giữ tên hướng dẫn / đăng ký ngắn. Những lý do đó không còn được áp dụng, nhưng tên mật mã ngắn vẫn rất phổ biến trong lập trình cấp thấp.

Tại sao lại thế này? Có phải chỉ vì thói quen cũ khó phá vỡ, hay có lý do nào tốt hơn?

Ví dụ:

• Atmel ATMEGA32U2 (2010?): TIFR1(Thay vì TimerCounter1InterruptFlag), ICR1H(thay vì InputCapture1High), DDRB(thay vì DataDirectionPortB), v.v.
• Tập lệnh .NET CLR (2002): bge.s(thay vì branch-if-greater-or-equal.short), v.v.

Không phải là tên dài hơn, không khó hiểu để làm việc với?

Khi trả lời và bỏ phiếu, xin vui lòng xem xét những điều sau đây. Nhiều cách giải thích có thể được đề xuất ở đây áp dụng như nhau cho lập trình cấp cao, và sự đồng thuận, nói chung, là sử dụng các tên không khó hiểu bao gồm một hoặc hai từ (các từ viết tắt thường được hiểu).

Ngoài ra, nếu đối số chính của bạn là về không gian vật lý trên sơ đồ giấy , vui lòng xem xét rằng điều này hoàn toàn không áp dụng cho ngôn ngữ lắp ráp hoặc CIL, cộng với tôi sẽ đánh giá cao nếu bạn chỉ cho tôi một sơ đồ trong đó các tên ngắn gọn nhưng dễ đọc làm cho sơ đồ tệ hơn . Từ kinh nghiệm cá nhân tại một công ty bán dẫn không khoan nhượng, những cái tên dễ đọc chỉ phù hợp và dẫn đến sơ đồ dễ đọc hơn.

Điều cốt lõi khác biệt về lập trình cấp thấp so với các ngôn ngữ cấp cao làm cho các tên khó hiểu khó hiểu trong lập trình cấp thấp nhưng không phải là cấp cao là gì?

Lý do phần mềm sử dụng các tên đó là vì các bảng dữ liệu sử dụng các tên đó. Vì mã ở mức đó rất khó hiểu nếu không có biểu dữ liệu, nên việc đặt tên biến bạn không thể tìm kiếm là vô cùng hữu ích.

Điều đó đặt ra câu hỏi tại sao datasheets sử dụng tên ngắn. Điều đó có thể là do bạn thường cần trình bày các tên trong các bảng như thế này khi bạn không có chỗ cho các số nhận dạng 25 ký tự:

Ngoài ra, những thứ như sơ đồ, sơ đồ pin và lụa xanh PCB thường rất chật chội cho không gian.

Luật của Zipf

Bản thân bạn có thể quan sát bằng cách nhìn vào chính văn bản này rằng độ dài từ và tần suất sử dụng, nói chung, có liên quan nghịch đảo. Nói cách được sử dụng rất thường xuyên, giống như it, a, but, you, và andrất ngắn, trong khi từ được sử dụng ít thường xuyên thích observe, comprehensionvà verbositydài hơn. Mối quan hệ được quan sát giữa tần suất và độ dài này được gọi là Định luật Zipf .

Số lượng lệnh trong bộ hướng dẫn cho một bộ vi xử lý nhất định thường là số hàng chục hoặc hàng trăm. Ví dụ: tập lệnh của Atmel AVR dường như chứa khoảng một trăm hướng dẫn riêng biệt (tôi không tính), nhưng nhiều trong số đó là các biến thể của một chủ đề chung và có các ký tự rất giống nhau. Ví dụ: các hướng dẫn nhân bao gồm MUL, MULS, MULSU, FMUL, FMULS và FMULSU. Bạn không cần phải xem danh sách hướng dẫn trong một thời gian dài trước khi bạn có ý tưởng chung rằng các hướng dẫn bắt đầu bằng "BR" là các nhánh, các hướng dẫn bắt đầu bằng "LD" là tải, v.v. Điều tương tự cũng áp dụng cho các biến: thậm chí các bộ xử lý phức tạp chỉ cung cấp một số nơi giới hạn để lưu trữ các giá trị: thanh ghi điều kiện, thanh ghi mục đích chung, v.v.

Bởi vì có rất ít hướng dẫn và vì tên dài mất nhiều thời gian hơn để đọc, nên đặt tên cho chúng là ngắn. Ngược lại, các ngôn ngữ cấp cao hơn cho phép các lập trình viên tạo ra một số lượng lớn các hàm, phương thức, lớp, biến, v.v. Mỗi trong số chúng sẽ được sử dụng ít thường xuyên hơn so với hầu hết các hướng dẫn lắp ráp, và các tên mô tả dài hơn ngày càng quan trọng để cung cấp cho độc giả (và nhà văn) đủ thông tin để hiểu chúng là gì và chúng làm gì.

Ngoài ra, các tập lệnh cho các bộ xử lý khác nhau thường sử dụng các tên tương tự cho các hoạt động tương tự. Hầu hết các tập lệnh bao gồm các thao tác cho ADD, MUL, SUB, LD, ST, BR, NOP và nếu chúng không sử dụng các tên chính xác đó, chúng thường sử dụng các tên rất gần nhau. Khi bạn đã học được tính năng ghi nhớ cho một bộ hướng dẫn, sẽ không mất nhiều thời gian để thích ứng với các bộ hướng dẫn cho các thiết bị khác. Vì vậy, những cái tên có vẻ "bí ẩn" đối với bạn là về như quen thuộc như những từ như and, orvà notđể lập trình viên có kỹ năng trong nghệ thuật lập trình ở mức độ thấp. Tôi nghĩ rằng hầu hết những người làm việc ở cấp độ lắp ráp sẽ nói với bạn rằng học đọc mã không phải là một trong những thách thức lớn hơn trong lập trình cấp thấp.

Nói chung

Chất lượng của việc đặt tên không chỉ là việc có các tên mô tả mà còn phải xem xét các khía cạnh khác, và điều đó dẫn đến các khuyến nghị như:

• phạm vi càng toàn cầu, tên càng được mô tả
• nó càng được sử dụng thường xuyên, tên càng ngắn
• cùng một tên nên được sử dụng trong tất cả các bối cảnh cho cùng một điều
• những thứ khác nhau nên có tên khác nhau ngay cả khi bối cảnh khác nhau
• các biến thể nên được phát hiện dễ dàng
• ...

Lưu ý rằng những khuyến nghị này là xung đột.

Hướng dẫn ghi nhớ

Là một lập trình viên ngôn ngữ lắp ráp, sử dụng short-branch-if-greater-or-equalcho bge.smang lại cho tôi ấn tượng tương tự như khi tôi thấy, như một lập trình viên Algol làm hình học tính toán, SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSthay vì dx := p2.x - p1.x. Tôi chỉ không thể đồng ý rằng cái đầu tiên dễ đọc hơn trong bối cảnh tôi quan tâm.

Đăng ký tên

Bạn chọn tên chính thức từ tài liệu. Các tài liệu chọn tên từ thiết kế. Thiết kế sử dụng nhiều định dạng đồ họa trong đó các tên dài không đủ và nhóm thiết kế sẽ tồn tại với các tên đó trong nhiều tháng, nếu không nói là nhiều năm. Vì cả hai lý do, họ sẽ không sử dụng "Cờ ngắt của bộ đếm thời gian đầu tiên", họ sẽ viết tắt nó trong lược đồ của họ cũng như khi họ nói. Họ biết điều đó và họ sử dụng các chữ viết tắt có hệ thống như TIFR1vậy để có ít cơ hội nhầm lẫn hơn. Một điểm ở đây là TIFR1không phải là viết tắt ngẫu nhiên, nó là kết quả của sơ đồ đặt tên.

Ngoài những lý do "thói quen cũ", mã Legacy được viết cách đây 30 năm và vẫn còn được sử dụng là rất phổ biến. Mặc dù một số người ít kinh nghiệm nghĩ, tái cấu trúc các hệ thống này để chúng trông đẹp mắt với chi phí rất cao cho một khoản lợi nhỏ và không khả thi về mặt thương mại.

Các hệ thống nhúng gần với phần cứng - và truy cập các thanh ghi, có xu hướng sử dụng các nhãn giống hoặc tương tự với các nhãn được sử dụng trong bảng dữ liệu Phần cứng, vì những lý do rất chính đáng. Nếu thanh ghi được gọi là XYZZY1 trong các bảng dữ liệu phần cứng, điều đó có nghĩa là Biến thể hiện nó có khả năng là XYZZY1 hoặc nếu lập trình viên đang có một ngày tốt lành, RegXYZZY1.

Theo như bge.s, nó tương tự như trình biên dịch chương trình - với một số ít người cần biết tên dài hơn thì ít đọc hơn. Nếu bạn không thể khiến bạn quay đầu bge.svà nghĩ branch-if-greater-or-equal.shortsẽ tạo ra sự khác biệt - bạn chỉ đang chơi với CLR và không biết điều đó.

Lý do khác mà bạn sẽ thấy các tên biến ngắn là do chúng tôi phổ biến các chữ viết tắt trong miền mà phần mềm đang nhắm mục tiêu.

Tóm lại - tên biến rút gọn ngắn phản ánh ảnh hưởng bên ngoài như định mức ngành và bảng dữ liệu phần cứng được mong đợi. Tên biến rút gọn ngắn là nội bộ của phần mềm thường ít được mong muốn hơn.

Có rất nhiều ý tưởng khác nhau ở đây. Tôi không thể chấp nhận bất kỳ câu trả lời hiện có như các câu trả lời: thứ nhất, có khả năng nhiều yếu tố góp phần vào đó, và thứ hai, tôi không thể nào biết cái nào là cái quan trọng nhất.

Vì vậy, đây là một bản tóm tắt các câu trả lời được đăng bởi những người khác ở đây. Tôi đang đăng bài này dưới dạng CW và ý định của tôi là cuối cùng đánh dấu nó được chấp nhận. Vui lòng chỉnh sửa nếu tôi bỏ lỡ một cái gì đó. Tôi đã cố gắng viết lại từng ý tưởng để diễn đạt nó một cách chính xác nhưng rõ ràng.

Vậy tại sao các mã định danh ngắn khó hiểu lại rất phổ biến trong lập trình cấp thấp?

• Bởi vì nhiều trong số chúng là đủ phổ biến trong miền tương ứng để đảm bảo một tên rất ngắn. Điều này làm xấu đi đường cong học tập, nhưng là một sự đánh đổi đáng giá với tần suất sử dụng.
• Bởi vì thường có một tập hợp nhỏ các khả năng được cố định (lập trình viên không thể thêm vào tập hợp).
• Bởi vì khả năng đọc là một vấn đề của thói quen và thực hành. branch-if-greater-than-or-equal.shortlà ban đầu dễ đọc hơn so bge.s, nhưng với một số thực tiễn tình hình trở nên đảo ngược.
• Bởi vì chúng thường phải được gõ đầy đủ, bằng tay, bởi vì các ngôn ngữ cấp thấp thường không đi kèm với các IDE mạnh mẽ có khả năng tự động hoàn thành tốt, hoặc a / c không đáng tin cậy.
• Bởi vì đôi khi mong muốn đóng gói nhiều thông tin vào mã định danh và một tên dễ đọc sẽ không được chấp nhận ngay cả theo tiêu chuẩn cấp cao.
• Bởi vì đó là những gì môi trường cấp thấp trông giống như trong lịch sử. Thói quen phá vỡ đòi hỏi nỗ lực có ý thức, có nguy cơ làm phiền những người thích những cách cũ và phải được coi là đáng giá. Bám sát theo cách đã thiết lập là "mặc định".
• Bởi vì nhiều trong số chúng có nguồn gốc ở nơi khác, chẳng hạn như sơ đồ và datasheets. Những người, lần lượt, bị ảnh hưởng bởi các hạn chế không gian.
• Bởi vì những người chịu trách nhiệm đặt tên mọi thứ thậm chí chưa bao giờ xem xét khả năng đọc hoặc không nhận ra rằng họ đang tạo ra một vấn đề hoặc lười biếng.
• Bởi vì trong một số trường hợp, các tên đã trở thành một phần của giao thức trao đổi dữ liệu, chẳng hạn như việc sử dụng ngôn ngữ hợp ngữ làm biểu diễn trung gian của một số trình biên dịch.
• Bởi vì phong cách này có thể nhận ra ngay lập tức là cấp thấp và do đó trông rất ngầu đối với các chuyên viên máy tính.

Cá nhân tôi cảm thấy rằng một số trong số này không thực sự đóng góp cho lý do tại sao một hệ thống mới được phát triển sẽ chọn kiểu đặt tên này, nhưng tôi cảm thấy sẽ sai khi lọc một số ý tưởng trong loại câu trả lời này.

Tôi sẽ ném mũ vào mớ hỗn độn này.

Các quy ước và tiêu chuẩn mã hóa cấp cao không giống như các tiêu chuẩn và thông lệ mã hóa cấp thấp. Thật không may, hầu hết trong số đó là sự nắm giữ từ mã kế thừa và các quá trình suy nghĩ cũ.

Một số, tuy nhiên, phục vụ một mục đích. Chắc chắn BranchGTHERThan sẽ dễ đọc hơn BGT rất nhiều , nhưng bây giờ có một quy ước, đó là một hướng dẫn và như vậy đã đạt được một chút lực kéo trong 30 năm sử dụng như một tiêu chuẩn. Tại sao họ bắt đầu với nó, có thể là một số giới hạn độ rộng ký tự tùy ý cho các hướng dẫn, biến và như vậy; Tại sao họ giữ nó, đó là một tiêu chuẩn. Tiêu chuẩn này giống như sử dụng int làm định danh, sẽ dễ sử dụng Integer hơn trong mọi trường hợp, nhưng có cần thiết cho bất kỳ ai lập trình hơn một vài tuần không ... không. Tại sao? Bởi vì đó là một thực hành tiêu chuẩn.

Thứ hai, như tôi đã nói trong nhận xét của tôi, nhiều ngắt được đặt tên INTG1 và các tên khó hiểu khác, chúng cũng phục vụ một mục đích. Trong các sơ đồ mạch, KHÔNG phải là quy ước tốt để đặt tên cho các dòng của bạn và như vậy rõ ràng nó làm tắc nghẽn sơ đồ và làm tổn thương tính dễ đọc. Tất cả sự dài dòng được xử lý trong tài liệu. Và vì tất cả các sơ đồ nối dây / mạch có các tên ngắn này cho các đường ngắt, bản thân các ngắt cũng có cùng tên với nhau để giữ tính nhất quán cho trình thiết kế nhúng từ sơ đồ mạch cho đến mã để lập trình.

Một nhà thiết kế có một số quyền kiểm soát đối với điều này, nhưng giống như bất kỳ lĩnh vực / ngôn ngữ mới nào, có các quy ước tuân theo phần cứng đến phần cứng và do đó sẽ giữ nguyên sự tương tự trên mỗi ngôn ngữ lắp ráp. Tôi có thể nhìn vào một đoạn lắp ráp và có thể nhận được ý chính của mã mà không cần sử dụng tập lệnh đó bởi vì chúng dính vào một quy ước, LDA hoặc một số liên quan đến nó có lẽ đang tải một MV đăng ký có lẽ đang chuyển một thứ gì đó từ đâu đó sang ở một nơi khác, nó không phải là về những gì bạn nghĩ là tốt đẹp hoặc là một thực tiễn cấp cao, đó là một ngôn ngữ tự nó và như vậy có tiêu chuẩn riêng của nó và có nghĩa là bạn là nhà thiết kế nên tuân theo, những điều này thường không tùy tiện như họ có vẻ.

Tôi sẽ để lại cho bạn điều này: Yêu cầu cộng đồng nhúng sử dụng các thực hành cấp cao dài dòng giống như yêu cầu các nhà hóa học luôn viết ra các hợp chất hóa học. Nhà hóa học viết chúng ngắn cho chính họ và bất kỳ ai khác trong lĩnh vực này sẽ hiểu nó, nhưng có thể cần một người mới đến một chút thời gian để điều chỉnh.

Một lý do họ sử dụng mã định danh ngắn khó hiểu là vì chúng không phải là mật mã cho các nhà phát triển. Bạn phải nhận ra họ làm việc với nó mỗi ngày và những tên đó thực sự là tên miền. Vì vậy, họ biết chính xác TIFR1 có nghĩa là gì.

Nếu một nhà phát triển mới đến với nhóm, anh ta sẽ phải đọc các bảng dữ liệu (như được giải thích bởi @KarlBielefeldt) để họ có thể thoải mái với những thứ đó.

Tôi tin rằng câu hỏi của bạn đã sử dụng một ví dụ tồi bởi vì thực sự trên các loại mã nguồn đó, bạn thường thấy rất nhiều mã định danh mật mã không cần thiết cho các công cụ không thuộc miền.

Tôi muốn nói rằng hầu hết họ làm điều đó vì những thói quen xấu tồn tại khi trình biên dịch không tự động hoàn thành mọi thứ bạn nhập.

Tóm lược

Chủ nghĩa ban đầu là một hiện tượng phổ biến trong nhiều giới kỹ thuật và phi kỹ thuật. Vì vậy, nó không giới hạn ở chương trình cấp thấp. Đối với các cuộc thảo luận chung, xem bài viết Wikipedia về Từ viết tắt . Câu trả lời của tôi là cụ thể cho lập trình cấp thấp.

Nguyên nhân của tên khó hiểu:

1. Hướng dẫn cấp thấp được gõ mạnh
2. Cần đóng gói nhiều thông tin loại vào tên của một lệnh cấp thấp
3. Trong lịch sử, mã ký tự đơn được ưa chuộng để đóng gói thông tin loại.

Giải pháp và nhược điểm của chúng:

1. Có những kế hoạch đặt tên cấp thấp hiện đại phù hợp hơn so với lịch sử.
   • LLVM
2. Tuy nhiên, nhu cầu đóng gói nhiều thông tin loại vẫn tồn tại.
   • Do đó, chữ viết tắt khó hiểu vẫn có thể được tìm thấy ở mọi nơi.
3. Cải thiện khả năng đọc từng dòng sẽ giúp một lập trình viên cấp thấp mới làm quen với ngôn ngữ nhanh hơn, nhưng sẽ không giúp hiểu được các đoạn mã cấp thấp.

Câu trả lời đầy đủ

(A) Tên dài hơn là có thể. Ví dụ, tên của C ++ SSE2 nội tại trung bình 12 ký tự so với 7 ký tự trong bản ghi nhớ lắp ráp. http://msdn.microsoft.com/en-us/l Library / c8c5hx3b (v = vs.80) .aspx

(B) Sau đó, câu hỏi chuyển sang: Mất bao lâu / không mật mã để nhận được từ các hướng dẫn cấp thấp?

(C) Bây giờ chúng tôi phân tích thành phần của các chương trình đặt tên như vậy. Sau đây là hai sơ đồ đặt tên cho cùng một hướng dẫn cấp thấp:

• Sơ đồ đặt tên số 1: CVTSI2SD
• Sơ đồ đặt tên số 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Các lệnh cấp thấp luôn được gõ mạnh. Không thể có sự mơ hồ, suy luận kiểu, chuyển đổi loại tự động hoặc quá tải (sử dụng lại tên lệnh để có nghĩa là các hoạt động tương tự nhưng không tương đương).

(C.2) Mỗi ​​lệnh cấp thấp phải mã hóa rất nhiều thông tin loại vào tên của nó. Ví dụ về thông tin:

• Gia đình kiến ​​trúc
• Hoạt động
• Đối số (Đầu vào) và Đầu ra
• Các loại (Số nguyên đã ký, Số nguyên chưa ký, Float)
• Độ chính xác (Độ rộng bit)

(C.3) Nếu mỗi phần thông tin được đánh vần, chương trình sẽ dài dòng hơn.

(C.4) Các sơ đồ mã hóa loại được sử dụng bởi các nhà cung cấp khác nhau có nguồn gốc lịch sử lâu dài. Ví dụ, trong tập lệnh x86:

• B có nghĩa là byte (8 bit)
• W có nghĩa là từ (16-bit)
• D có nghĩa là từ "từ kép" (32 bit)
• Q có nghĩa là qword "quad-word" (64-bit)
• DQ có nghĩa là dqword "double-quad-word" (128-bit)

Các tài liệu tham khảo lịch sử này không có ý nghĩa hiện đại nào, nhưng vẫn còn tồn tại. Một lược đồ phù hợp hơn sẽ đặt giá trị độ rộng bit (8, 16, 32, 64, 128) vào tên.

Ngược lại, LLVM là một bước đi đúng hướng theo tính nhất quán trong các hướng dẫn cấp thấp: http://llvm.org/docs/LangRef.html#fifts

(D) Bất kể chương trình đặt tên hướng dẫn, các chương trình cấp thấp đã dài dòng và khó hiểu vì chúng tập trung vào các chi tiết nhỏ của việc thực hiện. Thay đổi lược đồ đặt tên hướng dẫn sẽ cải thiện khả năng đọc ở cấp độ dòng, nhưng sẽ không loại bỏ khó khăn trong việc hiểu các hoạt động của một đoạn mã lớn.

Con người thỉnh thoảng chỉ đọc và viết lắp ráp, và hầu hết thời gian chỉ là một giao thức giao tiếp. Tức là, nó thường được sử dụng như một đại diện dựa trên văn bản nối tiếp trung gian giữa trình biên dịch và trình biên dịch. Đại diện này càng dài dòng thì càng có nhiều chi phí không cần thiết trong giao thức này.

Trong trường hợp opcodes và đăng ký tên, tên dài thực sự gây hại cho khả năng đọc. Ghi nhớ ngắn là tốt hơn cho một giao thức giao tiếp (giữa trình biên dịch và assember) và ngôn ngữ lắp ráp là một giao thức giao tiếp hầu hết thời gian. Ghi nhớ ngắn tốt hơn cho lập trình viên, vì mã trình biên dịch dễ đọc hơn.

Chủ yếu là thành ngữ. Như @TMN nói ở nơi khác, giống như bạn không viết import JavaScriptObjectNotationhoặc import HypertextTransferProtocolLibrarybằng Python, bạn không viết Timer1LowerHalf = 0xFFFFbằng C. Nó trông thật lố bịch trong ngữ cảnh. Mọi người cần biết đã biết.

Một phần, khả năng chống thay đổi có thể xuất phát từ việc một số nhà cung cấp trình biên dịch C cho các hệ thống nhúng đi lệch khỏi tiêu chuẩn ngôn ngữ và cú pháp để triển khai các tính năng hữu ích hơn cho lập trình nhúng. Điều này có nghĩa là bạn không thể luôn sử dụng tính năng tự động hoàn thành của IDE hoặc trình soạn thảo văn bản yêu thích của mình khi viết mã cấp thấp, bởi vì các tùy chỉnh này làm mất khả năng phân tích mã của chúng. Do đó tiện ích của tên đăng ký ngắn, macro và hằng.

Ví dụ, trình biên dịch C của HiTech bao gồm một cú pháp đặc biệt cho các biến cần có vị trí do người dùng chỉ định trong bộ nhớ. Bạn có thể tuyên bố:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Bây giờ IDE duy nhất tồn tại sẽ phân tích cú pháp này là IDE riêng của HiTech ( HiTide ). Trong bất kỳ trình chỉnh sửa nào khác, bạn sẽ phải nhập thủ công, từ bộ nhớ, mọi lúc. Điều này trở nên cũ rất nhanh chóng.

Sau đó, có một thực tế là khi bạn đang sử dụng các công cụ phát triển để kiểm tra các thanh ghi, bạn sẽ thường có một bảng được hiển thị với một số cột (tên đăng ký, giá trị trong hex, giá trị nhị phân, giá trị cuối cùng trong hex, v.v.). Tên dài có nghĩa là bạn phải mở rộng cột tên thành 13 ký tự để thấy sự khác biệt giữa hai thanh ghi và phát "phát hiện sự khác biệt" qua hàng chục dòng từ lặp lại.

Những điều này nghe có vẻ giống như những lời ngụy biện ngớ ngẩn, nhưng không phải mọi quy ước mã hóa được thiết kế để giảm mỏi mắt, giảm việc đánh máy không cần thiết hoặc giải quyết bất kỳ một trong số một triệu khiếu nại nhỏ khác?

Tôi ngạc nhiên khi không ai đề cập đến sự lười biếng và các ngành khoa học khác không được thảo luận. Công việc hàng ngày của tôi với tư cách là lập trình viên cho tôi thấy rằng các quy ước đặt tên cho bất kỳ loại biến nào trong một chương trình đều bị ảnh hưởng bởi ba khía cạnh khác nhau:

1. Nền tảng khoa học của lập trình viên.
2. Các kỹ năng lập trình của lập trình viên.
3. Môi trường của lập trình viên.

Tôi nghĩ rằng nó không có ích để thảo luận về lập trình cấp thấp hoặc cấp cao. Cuối cùng, nó luôn luôn có thể được ghim xuống ba khía cạnh trước đây.

Một lời giải thích về khía cạnh đầu tiên: Nhiều "lập trình viên" không phải là lập trình viên ngay từ đầu. Họ là những nhà toán học, nhà vật lý, nhà sinh học hay thậm chí là nhà tâm lý học hay nhà kinh tế nhưng nhiều người trong số họ không phải là nhà khoa học máy tính. Hầu hết trong số họ có từ khóa và chữ viết tắt tên miền cụ thể mà bạn có thể thấy trong "quy ước" đặt tên của họ. Họ thường bị mắc kẹt trong miền của họ và sử dụng những chữ viết tắt đã biết mà không nghĩ đến khả năng đọc hoặc hướng dẫn mã hóa.

Một lời giải thích về khía cạnh thứ hai: Vì hầu hết các lập trình viên không phải là nhà khoa học máy tính nên kỹ năng lập trình của họ bị hạn chế. Đó là lý do tại sao họ thường không quan tâm đến các quy ước mã hóa mà nhiều hơn về các quy ước cụ thể về miền như đã nêu ở khía cạnh đầu tiên. Ngoài ra nếu bạn không có kỹ năng lập trình viên, bạn không có hiểu biết về các quy ước mã hóa. Tôi nghĩ rằng hầu hết trong số họ không thấy nhu cầu cấp thiết để viết mã dễ hiểu. Nó như lửa và quên đi.

Một lời giải thích về khía cạnh thứ ba: Không thể can thiệp vào các quy ước của môi trường của bạn, đó có thể là mã cũ mà bạn phải hỗ trợ, các tiêu chuẩn mã hóa của công ty bạn (được điều hành bởi các nhà kinh tế không quan tâm đến tiền mã hóa) hoặc tên miền bạn thuộc về. Nếu ai đó bắt đầu sử dụng tên khó hiểu và bạn phải hỗ trợ anh ta hoặc mã của anh ta, bạn không có khả năng thay đổi tên mật mã. Nếu không có tiêu chuẩn mã hóa tại công ty của bạn, tôi cá là hầu hết mọi lập trình viên sẽ viết tiêu chuẩn của riêng họ. Và cuối cùng nếu bạn được bao quanh bởi những người dùng tên miền, bạn sẽ không bắt đầu viết một ngôn ngữ khác so với họ sử dụng.