Có một lý do chính đáng để sử dụng chữ hoa cho các từ khóa SQL không? [đóng cửa]

Mặc định có vẻ là chữ hoa, nhưng thực sự có lý do nào để sử dụng chữ hoa cho từ khóa không? Tôi bắt đầu sử dụng chữ hoa vì tôi chỉ cố gắng khớp với những gì SQL Server mang lại cho tôi bất cứ khi nào tôi cố gắng tạo một cái gì đó, như một thủ tục được lưu trữ mới. Nhưng sau đó, tôi cảm thấy thật tồi tệ với ngón tay của bé (thứ 5), luôn luôn cần giữ Shiftnút, vì vậy tôi đã ngừng sử dụng chữ hoa. Bất kỳ lý do tại sao tôi nên quay trở lại trường hợp trên?

Chỉnh sửa : Cảm ơn các câu trả lời kẻ. Tôi đã không lập trình trở lại vào thời mà COBOL là vua, vì vậy tôi không nhận thức được điều này. Tôi sẽ gắn bó với chữ thường từ bây giờ.

Đó chỉ là vấn đề về phong cách, có lẽ bắt nguồn từ thời mà các biên tập viên không làm mã màu.

Tôi đã từng thích tất cả các chữ hoa, nhưng bây giờ tôi nghiêng về tất cả các chữ thường.

CÁ NHÂN, TÔI KHÔNG THÍCH SQL CỦA TÔI VÀO TÔI. NÓ NHỚ TÔI CƠ BẢN HOẶC COBOL.

Vì vậy, tôi thích chữ thường T-SQL của mình với tên đối tượng cơ sở dữ liệu là MixedCase.

Nó dễ đọc hơn nhiều, và nghĩa đen và bình luận nổi bật.

SQL LÀ OLD. TRƯỜNG HỢP NỔI BẬT. NÓ DỄ DÀNG CHIẾN LƯỢC VÀ PERHAPS UGLY.

Mặc dù có thể đúng, nhưng không ai trong số đó giải thích lý do đặc biệt cho ngôn ngữ SQL tại sao từ khóa viết hoa là một quy ước tốt.

Không giống như nhiều ngôn ngữ mới hơn, SQL có số lượng từ khóa lớn và dựa vào khả năng của người đọc để phân biệt từ khóa với từ định danh để phân tích cú pháp một cách tinh thần.

Sau đó, câu trả lời trực tiếp cho câu hỏi của bạn là câu trả lời cho câu hỏi tại sao người đọc mã SQL lại hưởng lợi rất nhiều từ các từ khóa viết hoa, khi điều đó không đúng với hầu hết các ngôn ngữ hiện đại?

• Dựa vào việc giữ các từ khóa trong đầu là hợp lý đối với nhiều ngôn ngữ hiện đại, nhưng không hợp lý đối với SQL ; nó có quá nhiều từ khóa và quá nhiều biến thể.

• Dựa vào các dấu chấm câu là hợp lý đối với hầu hết các ngôn ngữ hiện đại, nhưng không hợp lý đối với SQL ; nó có quá ít, thay vào đó tùy thuộc vào thứ tự chính xác của từ khóa để chỉ ra cú pháp.

• Dựa vào các công cụ tô sáng tự động để phân biệt các từ khóa là hợp lý đối với các ngôn ngữ hiện đại trong các trường hợp thông thường, nhưng bỏ qua thực tế về những gì các công cụ tô sáng có thể đạt được cho SQL . Hầu hết không bao gồm tất cả các từ khóa của tất cả các biến thể của SQL và bất kể, SQL thường xuyên và thường xuyên được đọc trong các ngữ cảnh nơi một công cụ tô sáng sẽ không giúp ích.

Đây là một số lý do, cụ thể đối với SQL, rằng trình đọc mã SQL được phục vụ tốt nhất bằng cách tiêu chuẩn hóa chữ hoa cho từ khóa và chỉ sử dụng trường hợp không viết hoa (nghĩa là thấp hơn hoặc hỗn hợp) cho mã định danh.

Làm nổi bật đôi khi có thể giúp đỡ. Nhưng chỉ khi công cụ tô sáng biết bạn đã có SQL; và chúng ta rất thường có SQL trong bối cảnh mà trình soạn thảo / trình định dạng không thể biết một cách hợp lý nó đang xử lý SQL. Ví dụ bao gồm truy vấn nội tuyến, tài liệu lập trình viên và chuỗi văn bản trong mã của ngôn ngữ khác. Điều tương tự không đúng ở mọi nơi gần như thường xuyên đối với các ngôn ngữ như Python hoặc C ++; vâng, mã của họ đôi khi xuất hiện ở những nơi đó, nhưng nó không được thực hiện thường xuyên như với mã SQL.

Ngoài ra, người đọc thường sẽ sử dụng một công cụ tô sáng chỉ biết một tập hợp con các từ khóa mà việc triển khai SQL cụ thể của bạn sử dụng. Nhiều từ khóa ít phổ biến sẽ không được làm nổi bật trừ một từ khóa biết rõ biến thể SQL của bạn. Vì vậy, người đọc, ngay cả khi họ đang sử dụng công cụ tô sáng, vẫn cần một số cách phân biệt từ khóa trực tiếp hơn trong bất kỳ câu lệnh SQL phức tạp vừa phải nào.

Do đó, người đọc sẽ thường xuyên - và người viết không thể biết trước thời điểm đó - sẽ cần sự trợ giúp từ chính nội dung của câu lệnh SQL, để biết người viết dự định làm từ khóa và mục đích là định danh. Vì vậy, chính nội dung SQL cần phân biệt các từ khóa cho người đọc và sử dụng các từ khóa viết hoa là cách thông thường và hữu ích để làm điều đó.

Các ví dụ của Gordon Bell không chính xác; nói chung, chỉ các từ khóa được tô sáng, không phải toàn bộ truy vấn. Ví dụ thứ hai của anh ấy sẽ giống như:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Tôi thấy điều này dễ đọc hơn nhiều, vì các từ khóa nổi bật hơn. Ngay cả với đánh dấu cú pháp, tôi thấy ví dụ không được đánh giá cao khó đọc hơn nhiều.

Tại công ty của tôi, chúng tôi đi xa hơn một chút với định dạng SQL của chúng tôi.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

ĐÂY LÀ MỘT THỜI GIAN KHI NHỮNG NGƯỜI KHÁC NHẤT KHÔNG CÓ KHẢ NĂNG TÌM HIỂU BẤT CỨ VIỆC NÀO ĐỂ KIẾM ĐƯỢC CÁC TRƯỜNG HỢP NỀN TẢNG BEYOND TRỞ THÀNH TÌM HIỂU LIÊN QUAN (ASCII). CHỈ CẦN BITS S W CÓ S .N . KHI SQL LÀ NHẬN THÊM NHIỀU HƠN, THƯỞNG THỨC HẤP DẪN KHÔNG CÓ THỰC TIỄN THƯỜNG XUYÊN TRONG LẬP TRÌNH YET.

LƯU Ý R SNG MỘT SỐ NHÂN VIÊN YÊU CẦU R DATNG VIỆC CUNG CẤP S GET NHẬN ĐƯỢC MỘT KHẢ NĂNG KHẨN CẤP VÀ CHẠY NHANH CHÓNG CỦA BẠN NHANH CHÓNG.

Ít hơn 10% các chữ cái trong văn bản chúng tôi đọc là chữ hoa. Do đó bộ não của chúng ta nhạy bén hơn trong việc nhận ra chữ in thường so với chữ in hoa. Các nghiên cứu đã chỉ ra rằng cần nhiều thời gian hơn để đọc văn bản chữ hoa. Đây chỉ là một ví dụ:

http://www.guardian.co.uk/media/mind-your-lingu/2010/oct/04/new-york-street-signs-capitals

Ví dụ trên tôi nghĩ nhấn mạnh rằng ngay cả khi bạn đang nói về chỉ một hoặc hai từ, nó sẽ tạo ra sự khác biệt.

Đó là bởi vì SQL là một ngôn ngữ cũ ( 1974 ) mà khi nó được hình thành, hầu hết các bàn phím không có chữ thường! Các tài liệu ngôn ngữ chỉ đơn giản phản ánh công nghệ của thời gian.

Nghiên cứu đã chứng minh TẤT CẢ CAPS khó đọc hơn, đến nỗi Cơ quan Quản lý đường cao tốc Liên bang Hoa Kỳ đã bắt buộc sử dụng các biển báo trường hợp hỗn hợp trong Hướng dẫn sử dụng của họ trên Thiết bị kiểm soát giao thông thống nhất, trong đó nêu rõ:

Chữ viết tên của các địa điểm, đường phố và đường cao tốc trên các biển chỉ dẫn đường thông thường sẽ là sự kết hợp của các chữ cái viết thường với các chữ cái viết hoa ban đầu.

The New York Post cũng xuất bản:

Các nghiên cứu đã chỉ ra rằng việc đọc các biển báo mũ khó hơn và những mili giây thêm dành cho việc nhìn chằm chằm ra đường đã được chứng minh là làm tăng khả năng xảy ra tai nạn, đặc biệt là ở những người lái xe lớn tuổi.

Không có lý do chính đáng để sử dụng chữ in hoa, và lý do tốt để không.

Cá nhân tôi không thích sử dụng chữ hoa cho các từ khóa SQL. Tôi thấy khó đọc hơn và vô lý trong thời đại ngày nay.

Ngôn ngữ SQL được định nghĩa là không phân biệt chữ hoa chữ thường. Lấy ngón tay của bạn ra khỏi phím shift!

Chữ hoa có thể cung cấp mức tăng về khả năng hiển thị từ khóa, nhưng bạn có thể bù với phần tô sáng và thụt mã.
Chúng tôi sử dụng chữ thường vì trình soạn thảo truy vấn và các công cụ khác làm nên điều kỳ diệu trong việc chỉnh sửa mã t-sql và chúng tôi thấy không cần phải tra tấn ngón tay út.

Khỉ thấy, khỉ làm cho tôi. Khớp mẫu - nếu tôi thực hiện theo cách tôi đã thấy, cấu trúc của các mệnh đề sẽ dễ dàng hơn về mặt tinh thần.

Uppercase là ít đọc hơn. Các phác thảo của tất cả các từ có hình dạng như hộp; không có hậu duệ hay thăng thiên. Chữ thường FTW!

Tôi thấy nó dễ đọc hơn. Tương tự cho việc có một dòng mới cho phần đầu của mỗi mệnh đề và thụt vào giữa các mệnh đề.

Hãy thử một sản phẩm định dạng (Tôi sử dụng SQL Prompt / SQL Refactor từ Red Gate). Bạn có thể đặt cách bạn muốn viết hoa hoạt động và mã của bạn sẽ luôn được định dạng nhất quán. Nghỉ ngơi hồng hào của bạn và để máy tính làm việc cho bạn.

Một trong những lý do để tiếp tục sử dụng viết hoa là khi bạn (hoặc ai đó) đang xem mã trong một cái gì đó như notepad, nó giúp bạn dễ đọc hơn. tức là bạn có thể phân biệt dễ dàng giữa "từ khóa" và các tablenames, SP's, udf's, v.v.

Khác với sự phù hợp cho sự phù hợp vì lợi ích, không. Mặc dù đó là một chủ đề rất chủ quan, tôi thích sử dụng trường hợp hỗn hợp cho tất cả SQL. SQL dễ đọc hơn nhiều và không có gì bị mất trong các IDE hiện đại nơi các từ khóa đều được mã hóa màu.

Intellisense / autocompletion trong Microsoft SQL Server Management Studio cho phép viết hoa hoặc viết thường cho các từ dành riêng, nhưng các hàm viết hoa gọi như MAX (), SUM ().

Mặc dù vậy, trình phân tích cú pháp vẫn cho phép các phiên bản chữ thường của max () và sum () được xử lý.

Điều này ngụ ý một sự tương đồng liên quan đến bản chất của việc thực hiện, và do đó đơn giản chỉ là vấn đề sở thích cá nhân.

Tôi không thích bất cứ điều gì được viết trong tất cả các mũ (và ghét gõ tất cả các mũ hơn nữa), nhưng không thể thuyết phục bản thân đi ngược lại cộng đồng. Như thường lệ, Vim và các gói liên quan của nó là giải pháp cho rất nhiều vấn đề:

http://www.vim.org/scripts/script.php?script_id=305

Chỉ cần gõ như bình thường và nó sẽ tự động viết hoa các từ khóa khi bạn nhập. Tôi đã không sử dụng tất cả các câu thần chú SQL tối nghĩa nhưng nó vẫn chưa làm tôi thất bại.

Tôi gọi hầu hết mã myQuery của tôi từ bên trong PHP và tôi thực hiện tất cả các chỉnh sửa PHP của mình trong vim (hoặc tôi cho rằng trong trường hợp này là VIM ;-). Bây giờ tôi chắc chắn có các plugin ngoài đó để làm nổi bật mã myQuery trong PHP, nhưng tôi không tìm thấy nó và tôi không phải mất thời gian để tìm kiếm nó. Vì vậy, tôi thích có tất cả mọi thứ trong allcaps. Tôi tìm thấy điều này:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Giúp tôi phân biệt giữa PHP và SQL tốt hơn rất nhiều so với điều này:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Ngoài ra, vì một số lý do, tôi ghét trộn allcaps với vỏ lạc đà, như vậy:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

Điều đó làm IDtôi khó chịu. Thay vào đó nên id? hay iD?