Phong cách viết mã C cá nhân của tôi vào cuối năm 2023

• Tác giả bàn về phong cách viết mã C cá nhân của mình tính đến cuối năm 2023, nhấn mạnh những thay đổi và cải tiến quan trọng trong kỹ thuật.
• Tác giả bắt đầu dùng các tên ngắn cho kiểu nguyên thủy và nhận thấy điều này giúp tăng độ rõ ràng, đồng thời khiến việc rà soát mã trở nên thú vị hơn.
• Tác giả đưa ra ví dụ về quy ước đặt tên mới cho các kiểu nguyên thủy như typedef uint8_t u8; và typedef char16_t c16;.
• Tác giả áp dụng chữ thường cho các macro trông giống hàm, vì chúng dễ đọc hơn và không gặp các vấn đề về không gian tên như những định nghĩa macro khác.
• Tác giả ngừng dùng const, vì nó không có vai trò thực tế trong tối ưu hóa và cũng không bắt được lỗi. Họ tin rằng việc nó được đưa vào C là một sai lầm.
• Tác giả bác bỏ chuỗi kết thúc bằng null và chấp nhận kiểu chuỗi cơ bản, đồng thời nhận thấy cách này hiệu quả hơn.
• Tác giả ưu tiên trả về struct thay vì dùng tham số out, qua đó cho phép trả về nhiều giá trị một cách hiệu quả.
• Tác giả rời xa initializer và thích khởi tạo bằng phép gán hơn, ngoại trừ kiểu khởi tạo về 0 truyền thống.
• Tác giả thích __attribute hơn __attribute__, vì cho rằng cách sau quá rườm rà và không cần thiết.
• Với lập trình hệ thống Win32, tác giả khuyến nghị tự viết thủ công các prototype bằng cách dùng kiểu tự định nghĩa để giảm thời gian build, dọn dẹp không gian tên và giao tiếp sạch sẽ hơn với chương trình.
• Tác giả đưa ra các ví dụ về phong cách viết mã trong những chương trình nhỏ như wordhist.c và asmint.c.

[GN⁺]

Ý kiến trên Hacker News

• Bài viết về phong cách lập trình C mang tính cá nhân của tác giả vào cuối năm 2023.
• Một số người bình luận không đồng ý với cách tác giả tự định nghĩa các kiểu của mình, cho rằng điều này có thể gây nhầm lẫn cho những ai đã quen với các kiểu trong C.
• Có tranh cãi về việc dùng "ALL_CAPS" cho hằng số, và một số người cho rằng cách này nên được dành riêng cho macro tiền xử lý.
• Có ý kiến chỉ trích việc tác giả dùng kích thước có dấu, trong khi một số người bình luận cho rằng kích thước không dấu ít dễ phát sinh lỗi hơn.
• Việc tác giả đi chệch khỏi các quy ước hiện có, chẳng hạn dùng u8 hoặc i32 thay cho uint8_t hoặc int32_t, có vẻ khiến người khác bối rối.
• Một số người bình luận cho rằng cách tiếp cận của tác giả dường như tập trung nhiều hơn vào sở thích cá nhân thay vì làm cho mã C trở nên dễ cộng tác với mọi người.
• Có câu hỏi được đặt ra về việc tác giả dùng boolean 32-bit, và một số người cho rằng điều này làm lãng phí bộ nhớ mà không mang lại lợi ích rõ ràng.
• Có lo ngại về giả định của tác giả rằng float là 32-bit và double là 64-bit, và điều này có thể gây ra vấn đề.
• Khái niệm "phong cách cá nhân" trong lập trình bị cho là có thể mang tính vấn đề, vì lập trình về bản chất cuối cùng vẫn là một hoạt động mang tính xã hội, kể cả với các dự án sở thích.
• Một số người bình luận không đồng ý với việc tác giả ưu tiên struct hơn out-parameter, cho rằng điều này khiến hàm khó cấu thành hơn và làm gia tăng số lượng kiểu.
• Bài viết này đã khơi mào cho cuộc thảo luận về nhiều phong cách và cách tiếp cận lập trình khác nhau, nhấn mạnh sự đa dạng quan điểm trong cộng đồng lập trình.