Tiêu chuẩn mã hóa cho WordPress [Hướng dẫn]

Lý do mà chúng tôi có các tiêu chuẩn mã hóa (không chỉ cho WordPress) là để tạo môi trường quen thuộc cho lập trình viên làm việc trên một dự án. WordPress nói riêng bao gồm rất nhiều sản phẩm. Từ cốt lõi đến chủ đề và plugin, có rất nhiều thứ để xem xét - và rất nhiều thứ để lẫn lộn về.

Nếu mọi người định dạng mã của họ theo cùng một cách, sử dụng các nhận xét, cùng một kiểu tài liệu, v.v., làm việc cùng nhau sẽ trở nên dễ dàng hơn nhiều và quá trình học hỏi khi tham gia một dự án mới sẽ không quá dốc.

Nhu cầu về sự gắn kết trong WordPress được phóng đại bởi trạng thái của cơ sở mã. WordPress không tuân theo cách tiếp cận hướng đối tượng nghiêm ngặt và không sử dụng mô hình MVC. Các dự án tuân theo hướng dẫn OOP và MVC mà không có ngoại lệ (như Laravel) có tính nhất quán và thực tiễn tốt nhất “nướng trong” do cấu trúc của chúng.

Thật không may, WordPress đã chín muồi cho mã hóa spaghetti, hay còn gọi là làm bất cứ điều gì bạn muốn. Thực tiễn tốt nhất rất khó thực thi đơn giản vì các sản phẩm sử dụng mã xấu cũng có thể hoạt động tốt (trên bề mặt).

Bằng cách tuân theo Tiêu chuẩn mã hóa WordPress, bạn có thể tìm hiểu một chút về đặc điểm mã hóa của WordPress, tạo ra nhiều sản phẩm tương thích với WordPress hơn. cho cộng đồng thấy rằng bạn quan tâm và bạn sử dụng mã chất lượng cao.

Thêm thông tin trên Hongkiat.com:

10 cơn ác mộng tồi tệ nhất đối với các nhà phát triển web
5 lý do tại sao CSS có thể là ngôn ngữ khó nhất trong tất cả
30 lập trình viên phản ứng thường gặp khi mọi thứ trở nên sai lầm

Một số lưu ý về tiêu chuẩn

Các tiêu chuẩn không định nghĩa đúng sai. Bạn có thể không đồng ý với một quy tắc, ví dụ như luôn luôn nên sử dụng niềng răng, ngay cả khi không cần thiết. Mục đích của các tiêu chuẩn mã hóa WordPress không phải là quyết định bạn đúng hay sai, mà là quyết định cách thức thực hiện trong WordPress.

Các tiêu chuẩn không tranh luận. Việc sử dụng các tiêu chuẩn không phải là nơi để chống lại phong cách thụt đầu dòng mà bạn không thích. Nếu một cái gì đó nằm trong các tiêu chuẩn mã hóa thì hãy làm theo cách đó. Các nhà phát triển WordPress sẽ yêu bạn vì điều đó! Điều đó nói rằng, nếu bạn không đồng ý với điều gì đó trong đó, hãy lên tiếng và cho mọi người biết. Luôn luôn có thể làm mọi thứ tốt hơn nhưng bạn chỉ nên thay đổi phong cách mã hóa của mình nếu các tiêu chuẩn cho phép.

Sự nhất quán trong việc giữ lại hậu môn. Nếu bạn nằm trong 10% cuối cùng của dự án và bạn vừa phát hiện ra rằng bạn đã sử dụng quy ước đặt tên không chính xác cho các lớp, đừng chuyển giữa chừng. Theo ý kiến cá nhân của tôi, tôi thà đọc một cái gì đó không chính xác hơn là một cái gì đó đôi khi đúng và đôi khi không. Bạn luôn có thể viết một tập lệnh để thay đổi mọi thứ trong một lần hoặc đọc qua mã của bạn ở cuối.

Theo tiêu chuẩn là khó! Đặt một dấu ngoặc trên cùng một dòng với chức năng thay vì một dòng bên dưới là khá dễ dàng, ngay cả khi bạn đã quen nhấn enter trước đó. Tuy nhiên, khi bạn cần suy nghĩ về 100 quy tắc nhỏ, toàn bộ quá trình sẽ trở nên hơi lỗi. Mặc dù lập trường cứng rắn của tôi về việc tuân theo các tiêu chuẩn, tôi cũng có tội như bất kỳ ai khác về việc phạm sai lầm. Vào cuối ngày, thụt không chính xác không phải là một tội lỗi không thể chối bỏ. Cố gắng hết sức để tuân theo tất cả các quy tắc, bạn sẽ học mọi thứ kịp thời.

Tiêu chuẩn mã hóa WordPress

Hiện tại WordPress có bốn hướng dẫn, một cho mỗi ngôn ngữ chính được sử dụng: PHP, HTML, Javascript và CSS. Chúng tạo thành một phần của khối kiến thức lớn hơn, Cẩm nang cộng tác viên cốt lõi. Đi qua tất cả mọi thứ sẽ mất một lúc vì vậy tôi đã nhấn mạnh một số đoạn trong bốn ngôn ngữ mà tôi thường thấy mọi người hiểu sai.

PHP

PHP là ngôn ngữ chính của WordPress và là ngôn ngữ được gõ khá lỏng lẻo khiến nó trở nên chín muồi để điều chỉnh.

Kiểu giằng

Bắt đầu niềng răng phải luôn luôn được đặt ở cuối dòng. Các báo cáo liên quan nên được đặt trên cùng một dòng với dấu ngoặc đóng trước đó. Điều này được thể hiện tốt nhất với một ví dụ mã:

if (condition) // Do Something otherif (condition) // Do Something other // Do Something

Sử dụng không gian rộng rãi

Tôi không phải là một fan hâm mộ của mã bị bẹp (tôi có thị lực kém) vì vậy đây là một trong những điều tôi đặc biệt muốn thực thi. Đặt dấu cách sau dấu phẩy, và trên cả hai mặt của hợp lý, so sánh, chuỗi và toán tử gán, sau nếu, khác, cho, cho mỗi và công tắc điện báo cáo và như vậy.

Thật dễ dàng để nói nơi không nên thêm không gian! Lần duy nhất bạn không nên thêm dấu cách là khi đánh máy hoặc là tham chiếu mảng.

Một ngoại lệ khá khó hiểu cho ngoại lệ là các mảng trong đó khóa mảng là một biến, trong trường hợp này, sử dụng một khoảng trắng. Ví dụ này sẽ làm rõ điều này:

chức năng my_function ($ Complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ Complete_array) $ Final_array = $ Complete_array;  khác $ key_1 = (số nguyên) $ key_1; $ Final_array [0] = 'this'; $ Final_array [$ key_1] = 'là'; $ Final_array [$ key_2] = 'an'; $ Final_array ['last'] = 'example';  trả lại $ Final_array;

Quy ước đặt tên

Điều này có thể khó làm quen, đặc biệt nếu bạn đến từ các môi trường khác nhau. Tóm lại:

Tên biến nên là tất cả chữ thường, các từ được phân tách bằng dấu gạch dưới
Tên lớp nên sử dụng viết hoa ngăn cách bởi dấu gạch dưới. Các từ viết tắt nên là tất cả chữ hoa
Hằng số nên là tất cả chữ hoa, spearated bởi dấu gạch dưới
Tên tệp nên là tất cả chữ thường, ngăn cách với dấu gạch ngang

Điều kiện Yoda

Viết điều kiện theo cách khác hơn là bạn đã sử dụng sẽ ngăn ngừa lỗi phân tích cú pháp. Có vẻ hơi lạ nhưng đó là mã tốt hơn.

if ('Daniel' === $ name) echo 'Viết bài bạn sẽ';

HTML

HTML không có nhiều quy tắc liên quan đến nó, tôi có thể đưa ra khá nhiều thứ để biến mọi thứ thành mô-đun hơn. Chỉ có năm quy tắc bạn cần biết khi viết HTML:

Mã của bạn phải xác nhận hợp lệ với trình xác nhận W3C.
Các thẻ HTML tự đóng phải có chính xác một khoảng trắng trước dấu gạch chéo về phía trước (đây là thứ tôi cá nhân ghét, nhưng đó là thông số kỹ thuật của W3C, không chỉ là một tiểu cảnh thú cưng WordPress)
Các thuộc tính và thẻ phải là tất cả chữ thường. Ngoại lệ duy nhất là khi các giá trị thuộc tính có nghĩa là tiêu dùng của con người, trong trường hợp đó chúng nên được gõ một cách tự nhiên.
Tất cả các thuộc tính phải có một giá trị và phải được trích dẫn (viết không đúng)
Nên thụt lề bằng cách sử dụng các tab và phải tuân theo cấu trúc logic.

CSS

CSS là một ngôn ngữ được đánh máy lỏng lẻo khác vì vậy cũng có rất nhiều việc phải làm ở đây. Mặc dù vậy, các tiêu chuẩn khá dễ dàng đối với các lập trình viên.

Bộ chọn

Bộ chọn phải đủ tiêu chuẩn khi cần thiết, có thể đọc được bằng con người, tất cả đều là chữ thường với các từ được phân tách bằng dấu gạch ngang và bộ chọn thuộc tính nên sử dụng dấu ngoặc kép. Đây là một ví dụ ngắn gọn:

đầu vào [type = "text"], đầu vào [type = "password"], .name-field nền: # f1f1f1;

Đặt mua tài sản

Các tiêu chuẩn nhận ra sự cần thiết của một số không gian cá nhân ở đây vì chúng không quy định một thứ tự cụ thể cho các quy tắc CSS. Những gì họ làm nói là bạn nên theo một cấu trúc ngữ nghĩa có ý nghĩa. Nhóm thuộc tính theo mối quan hệ của họ hoặc nhóm chúng theo bảng chữ cái, đừng viết chúng ra một cách ngẫu nhiên.

Nguyên nhân lớn nhất cho sự ngẫu nhiên là “oh tôi cũng cần thêm một lề” và sau đó tiến hành thêm nó vào dưới cùng. Mất thêm 3 giây và thêm quy tắc vào vị trí hợp lý.

Trưng bày
Định vị
Mô hình hộp
Màu sắc và kiểu chữ
Khác

.profile-modal display: block; vị trí: tuyệt đối; bên trái: 100px; trên cùng: 90px; nền: # ff9900; màu: #fff;

Định dạng giá trị

Đây là một nơi mà tôi đặc biệt ghét nhìn thấy sự không nhất quán. Nếu bạn không tuân theo các nguyên tắc, điều đó vẫn tốt hơn là đôi khi nhìn thấy một khoảng trống trước giá trị; đôi khi sử dụng tốc ký, đôi khi không; đôi khi sử dụng đơn vị trên 0 giá trị, đôi khi không, v.v..

Định dạng giá trị khá phức tạp nhưng nó đến một cách tự nhiên với một số thực hành. Hãy xem hướng dẫn chính xác trong Codex để định dạng các giá trị của bạn.

Javascript

Theo kinh nghiệm của tôi, Javascript thường đi khắp mọi nơi. Mặc dù nhiều nhà phát triển biết một lượng đáng kể Javascript, nhưng nó đã được học dần dần, như là một cách để lại cho HTML, CSS và PHP. Khi bạn mới bắt đầu với một ngôn ngữ mới, bạn sẽ mắc nhiều lỗi hơn và nếu những sai lầm đó không gây ra lỗi nghiêm trọng, chúng có thể ăn sâu vào bạn.

Trong nhiều trường hợp, các tiêu chuẩn đề cập đến giới hạn dòng hoặc trạng thái “nếu một dòng không quá dài”. Điều này đề cập đến Hướng dẫn về Phong cách jQuery áp đặt một Giới hạn 100 ký tự trên dòng. Hướng dẫn WordPress dựa trên hướng dẫn jQuery, vì vậy, cũng nên đọc nó.

Dấu chấm phẩy

Đây là một quy tắc đơn giản nhất nhưng là một quy tắc thường bị bỏ qua. Không bao giờ, bỏ qua dấu chấm phẩy chỉ vì mã của bạn sẽ hoạt động mà không có nó. Nó thật cẩu thả.

Thụt lề

Tab luôn luôn được sử dụng để thụt lề. Bạn cũng nên thụt lề nội dung của một bao đóng ngay cả khi nội dung của toàn bộ tệp được chứa trong một. Tôi không chắc tại sao nhưng đóng cửa cấp cao nhất không được cấp phép đã làm phiền tôi ngay cả trước khi tôi đọc các tiêu chuẩn.

Đường phá vỡ

Khi ngắt chuỗi dài, luôn ngắt dòng sau toán tử, đừng để một biến treo. Điều này rõ ràng ngay từ cái nhìn đầu tiên rằng dòng bị hỏng và bạn chưa quên dấu chấm phẩy.

Ngoài ra, nếu một điều kiện dài, hãy chia nó thành nhiều dòng và thêm một tab phụ trước nó. Cái này trông rất kỳ lạ đối với mắt tôi nhưng sự tách biệt mà nó thêm vào giữa tình trạng và cơ thể là rất rõ ràng.

if (FirstCondition () && secondCondition () && thirdCondition ()) var html = 'Dòng này bao gồm các từ' + n + ', vì vậy nó nên được chia nhỏ sau' + 'một toán tử';

Lặp lại jQuery

Theo tiêu chuẩn lặp đi lặp lại của jQuery (jQuery.each ()) chỉ nên được sử dụng trên các đối tượng jQuery. Bạn nên sử dụng cơ bản cho, tại, trong khi các vòng lặp trong Javascript để lặp lại các bộ sưu tập khác.

Phần kết luận

Có rất nhiều điều cần lưu ý và theo dõi và không có cách nào ai đó có thể áp dụng tất cả điều này trong một lần. Bạn nên lấy mã của mình càng gần càng tốt với các tiêu chuẩn và làm việc theo chính xác chúng.

theo ý kiến của tôi nhất quán là quy tắc quan trọng nhất. Tốt hơn là liên tục làm một cái gì đó không chính xác hơn là chuyển nửa chừng. Điều này đặc biệt đúng với các thực tiễn định dạng vì chúng không ảnh hưởng đến chức năng của mã của bạn và - đối với hầu hết các phần - có thể dễ dàng thay đổi hàng loạt sau đó.

Bạn có ghét một yếu tố của các tiêu chuẩn mã hóa, bạn có nghĩ nên thêm cái gì đó không? Hãy cho chúng tôi biết trong các ý kiến!