Coding convention là gì? Tìm hiểu về coding convention java

oding convention là gì? Coding convention thường được sử dụng như thế nào trong lập trình? Cùng chúng tôi tìm hiểu về các quy tắc cùng cách sử dụng của Coding convention trong bài viết dưới đây.

Coding convention là gì?

Nội Dung Bài Viết

Coding convention là gì?
- Lý do nên sử dụng coding convention là gì
- Sử dụng Coding convention ở đâu và khi nào?
Coding Convention Java là gì
Coding convention C#
- Các quy tắc trong Coding convention C#
Coding convention Laravel
Coding convention PHP
Coding convention in C

Coding convention là gì?

Coding convention hay quy ước mã hóa là tiêu chuẩn định dạng mã thường được chấp nhận và sử dụng bởi một nhóm các nhà phát triển phần mềm để chia sẻ mã một cách thống nhất. Mục đích của việc áp dụng và sử dụng tiêu chuẩn là để một người đơn giản hóa việc hiểu mã chương trình và giảm thiểu tải về bộ nhớ, tư duy và tầm nhìn khi đọc một chương trình.

Ví dụ về tiêu chuẩn mã hóa là một tập hợp các quy ước được áp dụng trong bất kỳ tác phẩm in phổ biến nào bằng một ngôn ngữ (ví dụ: tiêu chuẩn C để viết mã, nhận được từ viết tắt K&R, xuất phát từ các cuốn sách cổ điển về C của Kernighan và Ritchie). Một ví dụ khác là thư viện hoặc API được sử dụng rộng rãi (ví dụ: việc phân phối ký hiệu Hungary rõ ràng bị ảnh hưởng bởi việc sử dụng nó trong Windows API và hầu hết các tiêu chuẩn mã hóa để sử dụng Python, ở mức độ này hay mức độ khác, các tiêu chuẩn PEP).

Các nhà phát triển ngôn ngữ cũng phát hành các hướng dẫn viết mã chi tiết. Ví dụ, các tiêu chuẩn mã hóa C # của Microsoft và các tiêu chuẩn mã hóa Java của Oracle đã được phát hành. Cách thức mã hóa do nhà phát triển đề xuất hoặc được chấp nhận bởi các nguồn nổi tiếng ít nhiều đã được bổ sung và hoàn thiện trong các tiêu chuẩn của công ty.

Thông thường, một tiêu chuẩn quy ước mã hóa mô tả:

Cách chọn tên và trường hợp ký tự được sử dụng cho tên biến và các số nhận dạng khác.
Viết kiểu của biến trong mã định danh của nó (ký hiệu tiếng Hungary) và một tập hợp các ký tự (chữ thường, chữ in hoa, “Lạc Đà”, “lạc đà” với chữ thường), sử dụng dấu gạch dưới để phân tách các từ.
Kiểu thụt lề cho các khối logic – có sử dụng các tab hay không, độ rộng thụt lề.
Một phương pháp để đặt các dấu ngoặc bao quanh các khối logic.
Việc sử dụng khoảng trắng trong thiết kế các biểu thức logic và số học.
Bình luận và việc sử dụng các bình luận tài liệu.
Các quy ước đặt tên biến, lớp và tệp,
Tuyên bố và các phương pháp hay nhất về việc sử dụng chúng.
Tổ chức hồ sơ.
Khai báo các lớp và giao diện.
Thực hành lập trình.

Ngoài tiêu chuẩn, những điều sau được ngụ ý:

Hạn chế kích thước của mã theo chiều ngang (để nó vừa với màn hình) và chiều dọc (để tất cả mã của tệp được lưu trong bộ nhớ).
Cũng như một hàm hoặc phương thức với kích thước của một màn hình (đối với một số ngôn ngữ lập trình).

Lý do nên sử dụng coding convention là gì

Các tiêu chuẩn mã hóa rất quan trọng đối với các nhà phát triển phần mềm vì một số lý do:

40% – 80% tổng chi phí của phần mềm được chi cho việc bảo trì nó.
Phần mềm hầu như không bao giờ được hỗ trợ đầy đủ bởi tác giả gốc của nó.
Các tiêu chuẩn mã hóa cải thiện khả năng đọc của phần mềm bằng cách cho phép các nhà phát triển hiểu mã mới nhanh hơn và tốt hơn.
Giống như bất kỳ sản phẩm nào khác, phần mềm phải được “đóng gói tốt” và sạch sẽ.

Như các nhà phát triển của Svitla Systems lưu ý, “Dự án nên được viết theo cùng một phong cách. Điều này là cần thiết để cải thiện hỗ trợ và tăng tốc độ liên quan đến các nhà phát triển mới và ngăn chặn việc viết ra các loại lỗi mới hoặc sử dụng các mẫu không cần thiết trong dự án, những nơi mà nó không cần thiết vào lúc này. “

Theo kinh nghiệm của chúng tôi, quy ước mã hóa cải thiện khả năng đọc mã, tạo điều kiện thuận lợi cho việc giới thiệu các nhà phát triển mới vào dự án và đơn giản hóa việc viết mã, bởi vì có sự hiểu biết về phong cách nó nên được viết và do đó ít cấu trúc lại sau này (nếu các tiêu chuẩn tốt viết với kiến trúc và cấu trúc).

Các lý do chính để sử dụng quy ước mã hóa như sau:

Các quy tắc viết mã tương tự giúp các đồng nghiệp khác dễ hiểu.
Dễ dàng hiểu mã hơn trong một năm hoặc 5 năm mà không cần đọc từng thuật ngữ.
Bạn luôn biết vị trí của các lớp và tệp nhất định trong một dự án lớn.

Điều này có thể được so sánh với một máy tính để bàn: Nếu mọi thứ được sắp xếp gọn gàng, nó rất dễ dàng để làm việc. Nếu có một mớ hỗn độn, thì mọi thứ nhỏ nhặt phải mất nhiều thời gian.

Thông thường, các quy ước viết mã cho mỗi nhóm là khác nhau, và đôi khi rất khác nhau giữa các dự án. Chúng tôi cần chúng để các nhà phát triển khác có thể dễ dàng tìm ra mã và nói chung, mã được viết bởi các thành viên trong nhóm khác nhau trông giống nhau trong dự án và có thể bảo trì và hỗ trợ.

Đối với các ngôn ngữ lập trình khác nhau, có các quy ước mã hóa. Những quy ước mã hóa này không phải là tuyệt đối. Trong mỗi dự án và mỗi công ty, các tiêu chuẩn có thể được phát triển cho quy ước mã hóa. Đây là một biểu đồ ví dụ:

Ngôn ngữ lập trình	Quy ước mã hóa
C	Kiểu mã hóa GNOME
C ++	Hướng dẫn kiểu Google C ++
C#	Quy ước mã hóa C # của Microsoft
Go	Các công cụ quy ước đặt tên và định dạng mã trong Golang
Java	Quy ước mã Java của Oracle
Javascript	Hướng dẫn về kiểu Javascript của Google
Python	PEP8
PHP	PSR-2
Ruby	Clearwater Ruby Coding Guidelin
Scala	Hướng dẫn phong cách Scala
Swift	Hướng dẫn về phong cách Swift của Google

Sử dụng Coding convention ở đâu và khi nào?

Cần lưu ý rằng quy ước mã hóa không chỉ là định dạng. Trả lời câu hỏi khi nào sử dụng quy ước mã hóa, tùy chọn dễ nhất là khi tự viết mã. Điều này cho phép tất cả những người tham gia dự án làm quen với quy ước và phối hợp tất cả các yêu cầu cần thiết.

Mã hóa quy ước phải được áp dụng bởi cả một nhà phát triển và một nhóm phát triển. Bất kể trình độ của các nhà phát triển, họ phải sử dụng quy ước mã hóa; điều này làm cho quá trình phát triển phần mềm ổn định hơn và mã trở nên tốt hơn.

Lưu ý rằng trong quá trình đánh giá ngang hàng phần mềm, việc tuân thủ quy ước mã hóa là rất quan trọng. Quá trình xác minh quy ước mã hóa cũng có thể được thực hiện trong quá trình tái cấu trúc. Điều này cải thiện khả năng đọc mã và làm cho toàn bộ dự án thống nhất hơn.

Tiêu chuẩn hóa các quy ước mã hóa có thể được thông qua ở các cấp độ sau:

Cấp độ dự án
Cấp công ty
Cấp cộng đồng nhà phát triển
Mức tiêu chuẩn ngành
Cấp độ ISO

Coding Convention Java là gì

Coding Convention Java được Oracle xác định trong tài liệu quy ước mã hóa. Tóm lại, các quy ước này yêu cầu người dùng sử dụng khi xác định các lớp, phương thức hoặc biến. Các class bắt đầu bằng một chữ cái viết hoa và phải là danh từ, như Calendar Dialog View. Đối với các phương thức, tên phải là động từ ở dạng mệnh lệnh, như get Brake System Type, và phải bắt đầu bằng một chữ cái viết thường.

Điều quan trọng là phải làm quen và tuân theo các quy ước mã hóa, để mã được viết bởi nhiều lập trình viên sẽ xuất hiện giống nhau. Các dự án có thể xác định lại các quy ước mã tiêu chuẩn để phù hợp hơn với nhu cầu của họ. Các ví dụ bao gồm danh sách các từ viết tắt được phép, vì chúng thường có thể làm cho mã khó hiểu đối với các nhà thiết kế khác. Tài liệu phải luôn đi kèm với mã.

Một ví dụ từ các quy ước mã hóa là cách xác định một hằng số. Hằng số phải được viết bằng chữ in hoa trong Java, trong đó các từ được phân tách bằng ký tự gạch dưới (‘_’). Trong các quy ước mã hóa Java, một hằng số là một static final trường trong một lớp.

Lý do cho sự chuyển hướng này là Java không phải là 100% hướng đối tượng và phân biệt giữa các kiểu “đơn giản” và “phức tạp”. Những điều này sẽ được xử lý chi tiết trong các phần sau. Một ví dụ cho một kiểu đơn giản là byte kiểu. Một ví dụ cho kiểu phức tạp là một lớp. Một tập hợp con của các kiểu phức tạp là các lớp không thể sửa đổi sau khi tạo, như a String, là một ghép các ký tự.

Ví dụ: hãy xem xét các “hằng số” sau:

1. hạng công cộng MotorVehicle {
2. / ** Số lượng động cơ * /
3. private static final int MOTORS = 1 ;
4. / ** Tên động cơ * /
5. private static final String MOTOR_NAME = “Mercedes V8” ;
6. / ** Đối tượng động cơ * /
7. private static final Motor THE_MOTOR = new MercedesMotor ();
8. / **

* Người xây dựng

public MotorVehicle () {
ĐỘNG CƠ = 2 ; // Đưa ra lỗi cú pháp vì MOTORS đã được gán một giá trị.
THE_MOTOR = ToshibaMotor mới (); // Đưa ra lỗi cú pháp vì THE_MOTOR đã được gán một giá trị.
MOTOR_NAME . toLowercase (); // Không đưa ra lỗi cú pháp vì nó trả về một Chuỗi mới thay vì chỉnh sửa biến MOTOR_NAME.
THE_MOTOR . fillFuel ( 20,5 ); // Không đưa ra lỗi cú pháp, vì nó thay đổi một biến trong đối tượng động cơ, chứ không phải chính biến đó.
}
}

Coding convention C#

Các quy ước mã hóa phục vụ các mục đích sau:

Chúng tạo ra một cái nhìn nhất quán cho mã, để người đọc có thể tập trung vào nội dung chứ không phải bố cục.
Chúng cho phép người đọc hiểu mã nhanh hơn bằng cách đưa ra các giả định dựa trên kinh nghiệm trước đó.
Chúng tạo điều kiện thuận lợi cho việc sao chép, thay đổi và duy trì mã.
Họ chứng minh các phương pháp hay nhất của C #.

Có một số quy ước đặt tên cần xem xét khi viết mã C #.

Trong các ví dụ sau, bất kỳ hướng dẫn nào liên quan đến các phần tử được đánh dấu public cũng có thể áp dụng khi làm việc với protected và protected internal các phần tử, tất cả đều nhằm mục đích hiển thị cho người gọi bên ngoài.

Các quy tắc trong Coding convention C#

Quy tắc đặt tên.

Có 3 kiểu đặt tên thông dụng nhất

Kiểu	Mô tả	Ví dụ
Pascal Case	Chữ cái đầu tiên trong từ định danh và chữ cái đầu tiên của mỗi từ nối theo sau phải được viết hoa. Sử dụng Pascal Case để đặt tên cho một tên có từ 3 ký tự trở lên.	Coding Convention
Camel Case	Chữ cái đầu tiên trong từ định danh là chữ thường và chữ cái đầu tiên của mối từ nối theo sau phải được viết hoa.	Coding Convention
Uppercase	Tất cả các ký tự trong từ định danh phải được viết hoa. Sử dụng quy tắc này đối với tên định danh có từ 2 ký tự trở xuống	System.IO

Tiền tố một số control.

Bắt buộc đặt tên cho tất cả các control có tham gia xử lý dưới nền. Một số control được đặt theo kiểu Pascal với phần tiền tố.

Quy ước viết câu lệnh.

Mỗi câu lệnh riêng rẽ trên một dòng.

Khối mã nguồn.

Sử dụng cặp dấu { } để đánh dấu một khối mã nguồn. Mỗi dấu ngoặc nằm trên một dòng (Ngoại lệ, kiểu enum, thuộc tính gọn hoặc khởi tạo giá trị cho mảng có thể không cần).

Trong các lệnh if, for, foreach, … nếu chỉ có một lệnh thì có thể không cần đánh dấu khối mã nguồn.

Thụt đầu dòng và cách khoảng

Viết cách vào một khoảng tab đối với các lệnh nằm trong khối lệnh { }.
Viết cách vào một khoảng tab đối với lệnh ngay sau if, else, while, for, foreach.
Viết cách một khoảng trắng xung quanh các toán tử 2 ngôi và 3 ngôi.
Viết cách một khoảng trắng sau dấu “,” và “;”.

Chú thích.

Nên comment trên những đoạn code khó hiểu hoặc chức năng đặc biệt. Ngôn ngữ sử dụng để chú thích phải đồng bộ xuyên suốt chương trình. Chọn một trong hai ngôn ngữ: tiếng Việt Unicode có dấu hoặc tiếng Anh.

Quy định chú thích:

Chỉ sử dụng // và /// để chú thích. Không dùng /* */.
Có chú thích trên đầu mỗi file source code mô tả chương trình, chức năng của chương trình, tác giả, v.v…
Khối xử lý dữ liệu: Có chú thích trên mỗi class, mỗi phương thức, mỗi thuộc tính của class mô tả chức năng, tham số, v.v…
Khối xử lý giao diện: Có chú thích mô tả chức năng trên mỗi phương thức không phải event, hàm Main.

Các kiểu chú thích:

Chú thích đơn giản.
Đoạn code phức tạp.
Mô tả trong thân hàm.
Mô tả field.
Đoạn code được người không phải tác giả sửa đổi.

Ngôn ngữ sử dụng.

Luôn luôn sử dụng kiểu dữ liệu C# thay vì kiểu dữ liệu .NET.

Coding convention Laravel

Laravel là một dự án mã nguồn mở và bất kỳ ai cũng có thể đóng góp cho Laravel để cải thiện nó. Chúng tôi hoan nghênh những người đóng góp, bất kể trình độ kỹ năng, giới tính, chủng tộc, tôn giáo hoặc quốc tịch. Có một cộng đồng đa dạng, sôi động là một trong những giá trị cốt lõi của khuôn khổ!

Để khuyến khích sự cộng tác tích cực, Laravel hiện chỉ chấp nhận các yêu cầu chứ không phải báo cáo lỗi. “Báo cáo lỗi” có thể được gửi dưới dạng một yêu cầu có chứa một bài kiểm tra đơn vị không đạt. Ngoài ra, một bản trình diễn về lỗi trong ứng dụng Laravel có thể được gửi dưới dạng một yêu cầu đến kho lưu trữ Laravel chính . Một thử nghiệm đơn vị hoặc ứng dụng không thành công cung cấp cho nhóm phát triển “bằng chứng” rằng lỗi tồn tại và sau khi nhóm phát triển giải quyết lỗi, nó đóng vai trò như một chỉ báo đáng tin cậy rằng lỗi vẫn được khắc phục.

Mã nguồn Laravel được quản lý trên Github và có các kho lưu trữ cho mỗi dự án Laravel:

Khung Laravel.
Ứng dụng Laravel.
Tài liệu Laravel.
Thu ngân Laravel.
Đặc phái viên Laravel.
Laravel Homestead.
Laravel Homestead Build Scripts.
Trang web Laravel.
Nghệ thuật Laravel.

Coding convention PHP

Các tiêu chuẩn mã hóa PHP này dành cho cộng đồng WordPress nói chung. Chúng là bắt buộc đối với WordPress Core và chúng tôi khuyến khích bạn sử dụng chúng cho các chủ đề và plugin của mình.

Cũng xem Tiêu chuẩn tài liệu nội tuyến PHP tại đây:

Mở và đóng thẻ PHP

Khi nhúng các đoạn mã PHP nhiều dòng trong một khối HTML, các thẻ mở và đóng PHP phải nằm trên một dòng của chính chúng.

Đúng (Nhiều dòng):

function foo() {

<div>

<?php

echo esc_html(

bar(

$baz,

$bat

)

);

</div>

<?php

}

Đúng (Dòng đơn):

1	<input name=”<?php echo esc_attr( $name ); ?>” />

Không đúng:

if ( $a === $b ) { ?>

<?php }

Không có thẻ PHP viết tắt

Quan trọng: Không bao giờ sử dụng thẻ bắt đầu PHP viết tắt. Luôn sử dụng các thẻ PHP đầy đủ. Chính xác:

1 2	<?php … ?> <?php echo esc_html( $var ); ?>

Không đúng:

1 2	<? … ?> <?= esc_html( $var ) ?>

Quy ước đặt tên

Sử dụng các chữ cái thường trong tên biến, hành động / bộ lọc và hàm (không bao giờ camelCase). Phân tách các từ qua dấu gạch dưới. Đừng viết tắt tên biến một cách không cần thiết; để mã rõ ràng và tự ghi lại.

1	function some_name( $some_variable ) { […] }

Tên lớp nên sử dụng các từ viết hoa được phân tách bằng dấu gạch dưới. Mọi từ viết tắt đều phải là chữ hoa.

1 2	class Walker_Category extends Walker { […] } class WP_HTTP { […] }

Các hằng số phải ở dạng chữ hoa với dấu gạch dưới ngăn cách các từ:

1	define( ‘DOING_AJAX’, true );

Các tệp phải được đặt tên mô tả bằng cách sử dụng các chữ cái thường. Dấu gạch nối nên ngăn cách các từ.

1	my-plugin-name.php

Tên tệp class phải dựa trên tên class có thêm chữ class – viết trước và dấu gạch dưới trong tên lớp được thay thế bằng dấu gạch ngang, ví dụ WP_Error: trở thành:

1	class-wp-error.php

Tiêu chuẩn đặt tên tệp này dành cho tất cả các tệp hiện tại và mới có các lớp. Có một ngoại lệ đối với quy tắc này cho ba tệp kế thừa : class.wp-dependencies.php,. Các tệp đó được thêm vào trước , một dấu chấm sau lớp từ thay vì dấu gạch ngang. class.wp-scripts.phpclass.wp-styles.phpclass.

Các tệp chứa thẻ mẫu trong thư mục wp-includes nên được – template thêm vào cuối tên để dễ thấy.

1	general-template.php

Coding convention in C

Một tệp Coding convention in C bao gồm các phần khác nhau nên được phân tách bằng một số dòng trống. Mặc dù không có giới hạn độ dài tối đa cho các tệp nguồn, nhưng các tệp có hơn 1000 dòng sẽ rất cồng kềnh để xử lý. Trình chỉnh sửa có thể không có đủ không gian tạm thời để chỉnh sửa tệp, quá trình biên dịch diễn ra chậm hơn, v.v. Nhiều hàng dấu hoa thị, ví dụ, hiển thị ít thông tin so với thời gian cần cuộn qua và không được khuyến khích. Các dòng dài hơn 79 cột không được xử lý tốt bởi tất cả các thiết bị đầu cuối và nên tránh nếu có thể. Các dòng quá dài do thụt lề sâu thường là một triệu chứng của mã có tổ chức kém. Dưới đây là các quy ước cần biết khi viết Coding convention in C:

Quy ước đặt tên tệp

Tên tệp được tạo thành từ tên cơ sở, dấu chấm và hậu tố tùy chọn. Ký tự đầu tiên của tên phải là một chữ cái và tất cả các ký tự (trừ dấu chấm) phải là chữ thường và số. Tên cơ sở phải có tám ký tự trở xuống và hậu tố phải có ba ký tự trở xuống (bốn, nếu bạn bao gồm dấu chấm). Các quy tắc này áp dụng cho cả tệp chương trình và tệp mặc định được chương trình sử dụng và tạo ra (ví dụ: “rogue.sav”).

Một số trình biên dịch và công cụ yêu cầu các quy ước hậu tố nhất định cho tên của tệp [5]. Các hậu tố sau là bắt buộc:

Tên tệp nguồn C phải kết thúc bằng.c.
Tên tệp nguồn của trình lắp ráp phải kết thúc bằng.s.
Các quy ước sau đây được tuân thủ phổ biến:
- Tên tệp đối tượng có thể di chuyển lại kết thúc bằng.o.
- Bao gồm các tên tệp tiêu đề kết thúc bằng .h. Một quy ước thay thế có thể thích hợp hơn trong môi trường đa ngôn ngữ là sử dụng hậu tố cho cả loại ngôn ngữ và .h(ví dụ: foo.c.h hoặc foo.ch).
- Tên tệp nguồn yacc kết thúc bằng.y.
- Tên tệp nguồn Lex kết thúc bằng.l.
C ++ có các quy ước hậu tố phụ thuộc vào trình biên dịch, bao gồm .c,, và . Vì nhiều mã C cũng là mã C ++ nên không có giải pháp rõ ràng nào ở đây…c.cc.c.c.C

Ngoài ra, thông thường sử dụng Makefile(không makefile) cho tệp điều khiển cho make (đối với các hệ thống hỗ trợ nó) và “README” để tóm tắt nội dung của thư mục hoặc cây thư mục.

File chương trình

Thứ tự được đề xuất của các phần cho một tệp chương trình như sau:

Đầu tiên trong tệp là đoạn mở đầu cho biết những gì có trong tệp đó. Mô tả về mục đích của các đối tượng trong tệp (cho dù chúng là hàm, khai báo hoặc định nghĩa dữ liệu bên ngoài hoặc một cái gì đó khác) hữu ích hơn một danh sách tên đối tượng. Phần mở đầu có thể tùy ý chứa (các) tác giả, thông tin kiểm soát sửa đổi, tài liệu tham khảo,…
Bất kỳ tệp tiêu đề bao gồm phải là tiếp theo. Nếu bao gồm vì một lý do không rõ ràng, lý do nên được ghi chú. Trong hầu hết các trường hợp, hệ thống bao gồm các tệp như stdio.h nên được đưa vào trước khi người dùng đưa vào tệp.
Tiếp theo là bất kỳ định nghĩa và typedef nào áp dụng cho toàn bộ tệp. Một thứ tự thông thường là phải có macro “hằng số” trước, sau đó đến macro “hàm”, sau đó là typedefs và enums.
Tiếp theo là khai báo dữ liệu toàn cục (bên ngoài), thường theo thứ tự: externs, không static global, static global. Nếu một tập hợp các định nghĩa áp dụng cho một phần dữ liệu toàn cục cụ thể (chẳng hạn như một từ flags), các định nghĩa phải nằm ngay sau khai báo dữ liệu hoặc được nhúng trong các khai báo cấu trúc, được thụt vào để đặt các định nghĩa sâu hơn một cấp so với từ khóa đầu tiên của tuyên bố mà họ áp dụng.
Các chức năng đến sau cùng và phải theo một thứ tự có ý nghĩa nào đó. Giống như các chức năng nên xuất hiện cùng nhau. Phương pháp tiếp cận “theo chiều rộng” (các chức năng ở mức độ trừu tượng tương tự với nhau) được ưu tiên hơn so với phương pháp đầu tiên theo chiều sâu (các chức năng được xác định càng sớm càng tốt trước hoặc sau cuộc gọi của chúng). Sự phán xét đáng cân nhắc được kêu gọi ở đây. Nếu xác định số lượng lớn các hàm tiện ích độc lập về cơ bản, hãy xem xét thứ tự bảng chữ cái.

Trên đây là tổng hợp các thông tin liên quan đến coding convention là gì cùng tổng hợp các thông tin, quy định về các tiêu chuẩn quy ước mã hóa cụ thể trong từng ngôn ngữ lập trình. Hy vọng rằng qua bài viết này các bạn sẽ hiểu hơn về coding convention là gì cùng các quy tắc của coding convention.

Xem thêm: Tổng hợp thông tin về tính chất của cạnh tranh là gì