1. Viết bài? Không hẳn vậy.
Viết mã nguồn đủ khác với viết một cuốn sách.
Mặc dù cả hai đều theo đuổi cùng một mục tiêu: càng rõ ràng càng tốt và dễ hiểu, họ đang thực hiện nó theo một cách rất khác, và những điều mà một nhà văn nên học không giống như những điều mà một nhà phát triển phần mềm nên học.
Ví dụ 1: số liệu của bài phát biểu
Số liệu của bài phát biểu có giá trị khi viết tiểu thuyết, thơ, v.v., vì chúng làm tăng tính biểu cảm của văn bản.
Lần cuối cùng bạn nhìn thấy một oxymoron hoặc một litote trong mã nguồn là gì? Nó sẽ giúp có được chúng, hay nó sẽ cực kỳ có hại cho bất kỳ nhà phát triển nào sẽ phải duy trì mã nguồn như vậy sau này?
Ví dụ 2: từ vựng
Vốn từ vựng phong phú được đánh giá cao trong văn học. Từ vựng của William Shakespeare, chẳng hạn, là hai mươi nghìn đến hai mươi lăm nghìn từ. Từ vựng phong phú hơn làm cho nó thú vị hơn để đọc một cuốn tiểu thuyết hoặc một bài thơ.
Khi bạn viết mã nguồn, bạn hy vọng nó sẽ được đọc bởi những người không nói tiếng Anh tốt . Cho thấy bạn biết tiếng Anh như thế nào sẽ cực kỳ có hại cho mã của bạn. Nếu bạn biết một từ ưa thích có nghĩa chính xác những gì bạn cần nhưng bạn biết rằng nhiều người không biết nghĩa của từ này, bạn nên tìm một từ đồng nghĩa ít biểu cảm hơn hoặc một nhóm từ giải thích nghĩa. Một từ vựng của một vài ngàn từ thường phần lớn là đủ cho một dự án nhất định.
Lưu ý một khía cạnh quan trọng: trong khi Google Dịch có thể giúp ích rất nhiều cho người không phải người bản ngữ, có hai vấn đề với bất kỳ người dịch nào:
Một cặp ngôn ngữ không nhất thiết phải có sự trùng khớp 1: 1 giữa các từ. Một số từ không có bản dịch trong các ngôn ngữ khác, hoặc nhiều từ có thể dịch thành một từ duy nhất bằng tiếng nước ngoài. Ví dụ, trong tiếng Nga, có một lượng lớn các từ nhắm vào các trạng thái cụ thể của tuyết và thời tiết lạnh, và việc dịch chúng sang tiếng Pháp hoặc tiếng Tây Ban Nha thường là không thể mà không làm mất tính đặc hiệu của chúng.
Một từ đôi khi có nhiều nghĩa và nghĩa được suy ra từ ngữ cảnh. Google Dịch, mặc dù chất lượng cao, thường không thể chỉ ra ý nghĩa cho bất kỳ tình huống cơ bản nào.
Ví dụ 3: biểu thức
Biểu hiện làm cho văn xuôi phong phú hơn là tốt. Một tác giả hy vọng người đọc có một lượng văn hóa chung nhất định và sử dụng cơ hội này để làm cho văn bản trở nên biểu cảm hơn.
Tương tự như ví dụ trước, các biểu thức như vậy có thể rất có vấn đề khi được đọc bởi những người không phải là người bản ngữ. Nhưng nếu từ vựng thông thường có thể được dịch, các thành ngữ có vấn đề hơn nhiều.
Chẳng hạn, tiếng Anh không phải là ngôn ngữ đầu tiên của tôi và trên cơ sở hàng ngày, tôi bắt gặp các biểu thức, kể cả ở đây trên StackExchange, mà tôi không biết. Tôi cố gắng đoán ý nghĩa của chúng, và đôi khi tôi đúng. Nhưng đôi khi tôi sai và làm cho những biểu hiện đó không có ích.
Một người dùng trong nhận xét của cô ấy / anh ấy đã nhắc nhở tôi về một ví dụ khiến tôi đau khổ trong một thời gian dài khi tôi mới bắt đầu lập trình: kim và cỏ khô của PHP . Tôi đã không nhận thức được con số tương ứng của bài phát biểu, vì vậy mỗi lần tôi đọc tài liệu, tôi đều tự hỏi tất cả những thứ này là về cái gì. Không cần phải nói rằng C # sequence.Contains(element)hay Python tuyệt vời element in sequencelà một sự thay thế tốt hơn nhiều. Chà, ít nhất, các nhà phát triển không biết tiếng Do Thái cũng phải chịu đựng PHP , nhưng đây là một câu chuyện khác.
Ví dụ 4: tài liệu tham khảo văn hóa
Tài liệu tham khảo văn hóa. Trong văn học, việc đưa vào các yếu tố từ một nền văn hóa nhất định là rất hấp dẫn và điều này cũng làm cho cuốn sách trở nên phong phú hơn và đôi khi thú vị hơn để đọc.
Tuy nhiên, mã được gửi đến các nhà phát triển từ khắp nơi trên thế giới. Do đó, một tài liệu tham khảo rõ ràng cho một nhà phát triển người Ý có thể không rõ ràng đối với một người Nga và điều mà mọi chàng trai hay cô gái Ấn Độ biết có thể không nhất thiết phải được một lập trình viên người Mỹ biết đến.
Chính người dùng đã nói về cây kim và đống cỏ khô đã đưa ra một ví dụ tuyệt vời về tài liệu tham khảo văn hóa như vậy: Chén Thánh. Ai không biết Chén Thánh là gì? Chà, ý tôi là, đó là Gra Gravio trong tiếng Pháp, kiểu Grial, tiếng Tây Ban Nha và ... từ Kutsal Kâse, trong tiếng Thổ Nhĩ Kỳ, nhưng vẫn còn. Tuy nhiên, có bao nhiêu nhà phát triển người Mỹ hay châu Âu biết lịch sử thời trung cổ của Trung Quốc hay Ấn Độ? Tại sao mọi người sẽ cho rằng mọi lập trình viên Trung Quốc và Ấn Độ đều phải biết tài liệu tham khảo Chén Thánh?
2. Bài học để viết mã nguồn biểu cảm? Chắc chắn rồi.
Bất kỳ nhà phát triển nào cũng nên học cách viết mã nguồn biểu cảm.
Bất kỳ nhà phát triển nên giải thích lý do tại sao bình luận trong:
int j = i + 1; // Creating i and adding 1 to it.
là xấu, thậm chí sang một bên thực tế là nó hoàn toàn sai.
Bất kỳ nhà phát triển nào cũng có thể hiểu được cấu trúc lại cơ bản và cách nó giúp làm cho mã nguồn trở nên biểu cảm hơn.
Bất kỳ nhà phát triển nào cũng nên nhớ rằng 20% thời gian được dành cho việc phát triển mã và 80% thời gian để duy trì nó. Đối với một số dự án, nó giống như 5% - 95%.
Vân vân.
Về bản chất, lập trình gần với tài liệu kỹ thuật. Có một người viết một tờ đặc tả cho một bu lông cần phải học bài viết? Không hẳn vậy. Điều tương tự áp dụng cho các nhà phát triển. Bất cứ ai cũng nên viết mà không mắc lỗi chính tả trong mỗi từ và bất kỳ ai cũng có thể truyền đạt ý tưởng của mình đủ rõ ràng. Bên cạnh đó, tôi không chắc cách viết bài học sẽ hữu ích hơn, giả sử, một khóa học về Khoa học máy tính hoặc bảo mật CNTT hay bất cứ điều gì.
Tính biểu cảm của mã nguồn có thể được học bằng các phương tiện khác. superM đã đề cập đến một trong số họ trong câu trả lời của mình : đọc mã tốt. Tôi có thể đề cập đến một vài người khác:
Đọc những cuốn sách như Code đẹp hoặc Code Complete,
Yêu cầu nhà phát triển có kinh nghiệm hơn để xem lại mã của bạn,
Hiểu các mẫu và làm thế nào và khi nào sử dụng chúng.