Cách đặt tên biến?

Jan 31 2023
Điều cần thiết là bạn phải tuân theo các quy ước đặt tên phù hợp khi viết mã để trở thành một nhà phát triển giỏi. Chắc chắn nó sẽ không thay đổi hiệu suất của mã, nhưng thời gian và công sức (hãy quên những đồng nghiệp của bạn đi) mà bạn sẽ yêu cầu để thực hiện các thay đổi trong mã hoặc gỡ lỗi mã của mình sẽ khiến bạn mất ngủ vài đêm.

Điều cần thiết là bạn phải tuân theo các quy ước đặt tên phù hợp khi viết mã để trở thành một nhà phát triển giỏi.

Chắc chắn nó sẽ không thay đổi hiệu suất của mã, nhưng thời gian và công sức (hãy quên những đồng nghiệp của bạn đi) mà bạn sẽ yêu cầu để thực hiện các thay đổi trong mã hoặc gỡ lỗi mã của mình sẽ khiến bạn mất ngủ vài đêm.

cảm ơn DALL E2 cho hình ảnh

lưu ý: bất cứ điều gì tác giả đã viết ở trên đều dựa trên các sự kiện có thật, không có gì là hư cấu. không nhận lời khuyên một cách tình cờ. cảm ơn đã đọc lưu ý :)

Quên x, y và i, j đi vì họ là người yêu cũ của bạn

để lại chúng khi bạn thực sự đang viết mã cho dự án, bạn có thể sử dụng chúng khi bạn đang lãng phí thời gian để lập trình cạnh tranh.

Đừng có thói quen đặt cho các biến của bạn những cái tên ngắn chẳng có ý nghĩa gì. Không đặt tên biến xhoặc y.

Đặt cho chúng những cái tên mô tả như numberOfDepositsLeftvà costOfItem.

Hãy tối ưu hóa cái này nữa, nếu bạn sử dụng itemCostthay vì costOfItemcái này thì tốt hơn.

Và đối với các biến kiểu boolean, hãy đặt câu hỏi về trạng thái của những thứ như -

IsActive, IsPaid, IsFloating, IsDeletable, v.v.

tiền boa không bắt buộc

đây là một mẹo không bắt buộc, nó được gọi là ký hiệu Hungary. một số người thích một số thì không. Thêm một định danh của loại biến làm tiền tố.

Vd: iLives (đối với số nguyên), fTokens (đối với số float), bIsAlive (đối với booleans), v.v. Để kiểm tra loại nhanh hơn là di chuột vào nó trong IDE của bạn.

Và hầu hết mọi người tránh nó vì lý do chính đáng. Nếu bạn dành nhiều thời gian để tự hỏi mình đang xử lý những loại nào, thiết kế của bạn có thể rất tệ. Thật khó để tôi nhớ lại mình đã từng dành quá nhiều thời gian để tìm ra điều đó đến mức tôi nghĩ mình nên thay đổi bất cứ điều gì.

bạn có thể sử dụng mẹo không bắt buộc này tùy thuộc vào cấu trúc dự án mà bạn sẽ thực hiện.

Bạn có thể bình luận, mã không bị xúc phạm bởi một bình luận

cố gắng thêm nhận xét vào mã của bạn để giải thích mọi thứ một chút vì khi bạn quay lại mã vào một ngày sau đó, bạn sẽ không hiểu được mớ hỗn độn đó. Nhận xét được phục vụ tốt nhất để cho bạn biết lý do tại sao bạn đã làm điều gì đó hơn là những gì bạn đã làm.

Theo ý kiến ​​​​của tôi, các nhận xét phải rất có ý nghĩa và không được sử dụng để thay thế mã hóa xấu.

Nếu bạn đang tuân theo Nguyên tắc thiết kế và phát triển của KISS, SOLID YAGNI, v.v. trong việc xây dựng các dự án của mình, rất nhiều điều bạn làm sẽ rất dễ hiểu. Ví dụ: nếu bạn xây dựng các hàm, chúng phải dễ hiểu với các tên mô tả và tên biến mô tả, mỗi lần chỉ thực hiện một việc.

Hãy kiểm tra Twitter của tôi

Cảm ơn bạn đã dành thời gian, hy vọng bạn thích điều này ❤️