Tiêu chuẩn coding trong Java (Coding Standards) - GP Coder (Lập trình Java)

Trong bài viết này tôi sẽ ra mắt với những bạn tiêu chuẩn coding trong Java và tầm quan trọng của việc viết code theo chuẩn. Mỗi ngôn từ lập trình và dự án Bất Động Sản tăng trưởng sẽ có những tiêu chuẩn khác nhau. Phạm vi trong bài này chỉ ra mắt một vài tiêu chuẩn chung của ngôn từ lập trình Java .Nếu những bạn là người mới mở màn tìm hiểu và khám phá về Java hoặc đã biết về Java nhưng chưa biết coding standard là gì thì hãy dành ít thời hạn đọc qua và vận dụng .

Tiêu chuẩn coding là gì ?

Tiêu chuẩn coding ( Coding Standards ) là một bộ quy tắc pháp luật cách viết code của một chương trình mà lập trình viên phải tuân theo khi tham gia vào dự án Bất Động Sản tăng trưởng chương trình đó. Tùy theo mỗi dự án Bất Động Sản mà sẽ có những tiêu chuẩn khác nhau, bộ quy tắc đó gồm có :

Đặt tên lớp, interface, tên biến, phương thức, …
Khoảng trắng, tab
Khai báo và sử dụng biến
Comment mã nguồn: tên người tạo, phiên bản, ngày tạo file, lớp, phương thức, người thay đổi, nội dung thay đổi, …
Độ dài tối đa mỗi dòng code, mỗi file, …
…..

Tầm quan trọng của tiêu chuẩn coding

Dễ bảo trì, sửa lỗi.
Để người khác hiểu được mã nguồn của mình.

Bạn đang đọc: Tiêu chuẩn coding trong Java (Coding Standards) – GP Coder (Lập trình Java)
Thống nhất code giữa những thành viên trong nhóm .

Bạn là một Debugger xuất sắc, có người nhờ bạn sửa lỗi chương trình giúp họ :

Bạn cảm thấy như thế nào nếu được nhận bảo dưỡng đoạn code này so với đoạn code trên :

Tiêu chuẩn coding là một thành phần rất quan trọng trong tăng trưởng ứng dụng. Tuy nhiên, nó thường bị bỏ lỡ hoặc chỉ vận dụng quy trình tiến độ đầu, về sau lại bị bỏ quên .Một tiêu chuẩn mã hoá đồng điệu sẽ giúp cải tổ chất lượng của mạng lưới hệ thống ứng dụng tổng thể và toàn diện. Chìa khóa cho một tiêu chuẩn mã hóa tốt là tính đồng điệu. Sự đồng điệu này cần được tìm thấy trong tiêu chuẩn ( nói cách khác, bạn cần bảo vệ rằng những nguyên tắc không xích míc nhau ) mà còn trong mã nguồn sử dụng tiêu chuẩn. Mã nguồn đã hoàn thành xong nên phản ánh một phong thái hòa giải, như thể một nhà tăng trưởng đã viết mã trong một chương trình .Nếu bạn là người duy nhất hoàn toàn có thể hiểu được mã ( cả cấu trúc và tính năng ), bạn sẽ là người duy nhất hoàn toàn có thể thực thi đổi khác và sửa lỗi cho mã đó. Đây là những gì bạn muốn, phải không ? Bằng cách đó, bạn sẽ không khi nào hoàn toàn có thể để lại loại sản phẩm đó cho người khác và tạm ứng sự nghiệp của bạn .Mã nguồn hoàn toàn có thể đọc được nhiều hơn thì thuận tiện hơn cho người nào đó duy trì mã đó. Bằng cách theo một phong thái đồng nhất, nó được cho phép những nhà tăng trưởng khác bước vào và giúp bảo dưỡng hoặc tăng trưởng mới .Bằng cách tạo mã nguồn dễ hiểu hơn cho nhà tăng trưởng, sẽ thuận tiện tìm và sửa lỗi hơn. Nó cũng phân phối một cái nhìn tốt hơn về phương pháp mã đó tương thích với ứng dụng lớn hơn, và trong 1 số ít trường hợp, công ty như một toàn thể. Quan điểm rõ ràng hơn này hoàn toàn có thể dẫn đến năng lực tái sử dụng mã nhiều hơn, hoàn toàn có thể có ảnh hưởng tác động đáng kể đến ngân sách và nỗ lực tăng trưởng .Cũng có một yếu tố tâm ý đóng vai trò khi vận dụng những tiêu chuẩn mã. Yếu tố này là cảm xúc “ quyền sở hữu mã ”. Quyền sở hữu mã tương quan đến cảm xúc tự hào về chất lượng việc làm đã triển khai và mong ước thấy mã ( mẫu sản phẩm ) đó hoạt động giải trí tốt. Mức sở hữu càng cao, chất lượng càng trở nên tốt hơn .

Chuẩn hình thức và chuẩn ngữ nghĩa

Chuẩn hình thức

Là những pháp luật tương quan đến sự định dạng của mã nguồn :

Thụt đầu dòng
Sử dụng khoảng trắng
Đóng ngoặc, mở ngoặc
Đặt tên lớp, thuộc tính, phương thức

Chuẩn ngữ nghĩa

Là những pháp luật tương quan đến sự thực thi của mã nguồn

Biểu thức so sánh
Cấu trúc điều khiển : if, for, while
Khai báo và sử dụng biến
Cài đặt phương thức

White Space

Những pháp luật về sử dụng khoảng chừng trắng ( space ), thụt đầu dòng, xuống dòng, dòng trống : giúp cho nội dung văn bản được tổ chức triển khai một cách có mạng lưới hệ thống để người đọc thuận tiện tiếp thu .

White Space – thụt đầu dòng

Xác định một chuẩn thụt đầu dòng cho hàng loạt mã nguồn của chương trình .

1 đơn vị thụt đầu dòng = 1 tab(*)
Hoặc, 1 đơn vị thụt đầu dòng = 5 khoảng trắng

Dòng code thứ 20 dùng 2 đơn vị chức năng thụt đầu dòng nghĩa là bấm tab 2 lần ( * )Nên dùng tab thay cho khoảng chừng trắng

Đỡ tốn công nhập quá nhiều lần khoảng trắng
Có thể tùy chỉnh một đơn vị tab ứng với bao nhiêu khoảng trắng tùy ý

Hai dòng code cách nhau một bậc thì sẽ cách nhau một đơn vị chức năng thụt đầu dòng .

White Space – Dòng trống

Những dòng code có quan hệ với nhau ( cùng thực thi một việc làm ) thì gom lại thành một block .Nghĩa là không có dòng trống giữa những đoạn code như trên .Hai block code thì cách nhau tối thiểu một dòng trống .Đặt khoảng chừng trắng sau dấu phẩy và dấu chấm phẩy .Đặt khoảng chừng trắng xung quanh những toán tử .

Ngoặc tròn ()

Dùng dấu ngoặc tròn để :

Người đọc hiểu rõ mục tiêu của bạn .
Chắc chắn là trình biên dịch sẽ thực thi đúng theo ý của bạn .

Hãy quyết định hành động dùng dấu ngoặc tròn khi bạn đang phân vân là có nên dùng dấu ngoặc tròn hay không .

Dấu ngoặc nhọn { }

Theo tiêu chuẩn Java : dấu “ { ” phải được đặt cùng dòng với những câu if, for, while, … Nếu bạn nào đã code với C # thì sẽ thấy ngược lại, dấu “ { ” phải được đặt ở dòng mới .

Không viết những comment chỉ lặp code, comment thừa. Một số yếu tố gặp phải khi comment không tốt :

Các comment chỉ mô tả là lặp code, chứ không cung cấp thêm thông tin gì cho người đọc.
Làm code dài hơn.
Người đọc tốn thời gian đọc nhiều hơn.

Viết những comment không cầu kì ; càng đơn thuần càng tốt .Khi dùng nhiều endline comment trên những dòng code liên tục nhau thì những comment này phải được canh lề như nhau .Nên vừa code vừa viết comment. Tránh trường hợp viết code xong rồi mới viết comment .Không nên đụng chỗ nào cũng comment, chỉ viết comment khi bạn cảm nhận là đoạn code của mình quá phức tạp .

Quy ước đặt tên

Quy tắc viết hoa

Pascal case

Các chữ cái đầu mỗi từ được viết hoa.
Các chữ còn lại được viết thường.
Ví dụ: MyProvider, StringBuilder

Camel case

Giống với Pascal case nhưng chữ cái đầu của từ đầu tiên viết thường.
Ví dụ: myProvider, stringBuilder

Đặt tên class, interface, abstract class

Sử dụng danh từ hay cụm danh từ : SinhVien, FormSinhVien, …

Dùng Pascal case : SinhVien, FormSinhVien,…

Hạn chế viết tắt gây khó hiểu :

Sai: FormSV
Đúng:FormSinhVien

Không dùng tiền tố khi đặt tên lớp :

Sai : ISinhVien
Đúng: SinhVien

Phương thức

Sử dụng Camel case để đặt tên phương thức. Ví dụ: xepLoai.

Tên phương thức thể hiện được chức năng của phương thức đó. tinhDiemTrungBinh.

Xem thêm: Abstract class và Interface trong Java

Tránh đặt tên gây cảm xúc mơ hồ, không rõ nghĩa. Ví dụ : hienThi, tinh .Không phân biệt tên những phương pháp bằng số. Ví dụ : tinhDiem1, tinhDiem2 .

Biến

Sử dụng Camel case để đặt tên biến. Ví dụ: int diemTrungBinh, String hoTen

Không dùng tiền tố. Ví dụ :

Đúng: String address
Sai: String strAddress

Tên biến gợi nhớ, tránh viết tắt gây khó hiểu. Ví dụ :

Đúng: String address
Sai: String addr

Không đặt tên biến chỉ bằng 1 vần âm như x, y, z, … trừ trường hợp những biến đếm i, j, k .Không nên đặt tên biến quá dài, hay quá ngắn vì hoàn toàn có thể làm rối chương trình hoặc cũng dẫn đến ý nghĩa biến mơ hồ ( quá ngắn ) .

Biến static, enum

Tất cả những từ được viết hoa và phân làn bằng dấu gạch dưới ( _ ) .Ví dụ :

static float PI = 3.14f
static int MIN_WIDTH = 4

enum ShapeType{
	SQUARE, CIRCLE, RECTANGLE
}

Biến final

Đối với biến final toàn cục : đặt tên biết giống như biến static. Tất cả những từ được viết hoa và ngăn cách bằng dấu gạch dưới ( _ ) .Đối với biến fianl cục bộ : đặt tên biến giống như biến thường thì .

public class HinhTron {
	// Biến toàn cục
	final float PI = 3.14f;

	public float tinhChuVi(int banKinh) {
		int duongKinh = banKinh * 2; // Biến cục bộ
		return duongKinh * PI;
	}
}

Đặt tên package

Tên package : toàn bộ đều là chữ thường .Ví dụ :

Đúng: com.example.deepspace
Sai: com.example.deepSpace hoặc com.example.deep_space

Viết một phương pháp hiệu suất cao

Khi một đoạn code Open ở nhiều nơi trong chương trình ta gom những đoạn code đó thành một phương pháp : Tiết kiệm thời hạn bảo dưỡng, sửa lỗi .Khi trong một phương pháp có những đoạn code giải quyết và xử lý phức tạp thì ta nên tách đoạn code phức tạp đó ra thành một phương pháp riêng không liên quan gì đến nhau : Dễ dàng theo dõi, debug .Khai báo tham số truyền vào vừa đủ, tránh thực trạng khai báo tham số truyền vào nhưng không sử dụng .Mỗi phương pháp chỉ thực thi một tính năng .Kích thước của một phương pháp : Nhiều thí nghiệm cho thấy một phương pháp có khoảng chừng từ 50 đến 150 dòng code là hài hòa và hợp lý. ( Trích Steve McConnell, Chapter 7.4 – Code Complete, Second Edition. 2004 ) .Ví dụ :

Phương thức tinhVaHienThiDiem và tinhVaLuuDiemDiem :

Trùng lặp code tinhDiem, mỗi khi có thay đổi cách tính điểm phải đi sửa ở 2 nơi.
Một phương thức sử dụng cho 2 mục đích: nếu code tính điểm và code hiển thị hay lưu điểm phức tạp sẽ rất khó để bảo trì và đọc hiểu.

Nên tách ra những phương pháp : tinhDiem, hienThiDiem, luuDiemPhương thức getHoTen chỉ cần họ và tên, không sử dụng tham số chữ lót .

Sử dụng biến ( variables )

Tránh thực trạng khai báo biến mà không sử dụng : nhiều trình biên dịch warning khi complie ( Eclipse IDE ) .Các lệnh if, while, for không nên lồng nhau hơn 3 bậc .

Import thư viện sử dụng

Chỉ import thư viện sử dụng thiết yếu. Không sử dụng import tổng thể .

Ví dụ: sử dụng import java.util.List; thay cho import java.util.*;

Tham khảo những chuẩn mã nguồn

Google Java Style GuideJava_standards_v1. 0 _ ( NEAF )JavaCodingConvention_Sun_19975.0

Xem thêm: Top 10 cuốn sách lập trình Java hay nhất mọi thời đại – https://final-blade.com

Nếu bạn thấy hay thì hãy chia sẻ bài viết cho mọi người nhé!

Bình luận

phản hồi

Source: https://final-blade.com
Category: Kiến thức Internet

admin

final-blade.com