Услуги Сертификаты Новости Статьи База знаний Алгоритмы Портфолио Скачать Ссылки Поиск
Услуги arrow Статьи arrow Code Usability: оптимальность заполнения кода на странице
Code Usability: оптимальность заполнения кода на странице Версия для печати Отправить на e-mail
13.07.2009

Код можно писать по-разному. Можно писать подробно, можно кратко. Все зависит от каждого конкретного программиста. Но, можно найти золотую середину, такой стиль написания кода, когда и вы, и другие программисты, которые будут (возможно) читать ваш код, сразу его поймут.

Критерием оценки оптимальности кода может выступать ваше собственное мнение по поводу своего же кода, не обязательно чужого.

Например: вы пишете код, выполняете рефакторинг, проверяете его не оптимальность. Ваш код вам нравится. Сегодня нравится.

Но, взглянув на него через несколько месяцев, вам он уже не понравился.

Почему? Ваши навыки написания кода улучшились, вы считаете, что код можно было бы написать иначе. Красивее, так сказать. Я не говорю, что нужно бросаться и переписывать ваш прежний код. Я говорю о том, что новый код вы можете написать лучше.

На мой взгляд, хороший код должен обладать следующими качествами:

  1. Должен быть читаем и однозначен для понимания, должен быть краток и лаконичен.
  2. Должен иметь оптимальное заполнение на одной экранной странице монитора со среднестатистическим разрешением (например, 1024х768). Не должен содержать излишние пустые строки и пробелы.
  3. Размер кода метода класса не должен по возможности превышать одного экрана вашего монитора. Это улучшит его восприятие.
  4. Если условный оператор содержит одну строку кода в исполняемой секции и строка небольшой длины (не превышает ширину экрана в 1,5 раза), можно записать условие и выполняемый код в одну строку. При условии, что код не станет от этого нечитаемым.
  5. Сложный код нужно выделять пустыми строками впереди и позади участка кода. Это улучшит его понимание.
  6. Однотипные операции можно объединять в блоки, которые в общем коде можно выделять пустыми строками впереди и позади блока кода.
  7. Условные операторы многих языков позволяют не выделять исполняемый по условию код оператором начала и конца блока кода. Но я считаю, что даже одну строку кода нужно выделять признаками начала и конца блока. Лучше записать код условия и выполняемый код в одну строку, чем записать в две строки, но не выделить исполняемый блок кода. Причина - если вы пишете код в среде разработки, среда автоматически проставляет табуляцию и код корректно отобразится после условного оператора. Но если ваш код будут просматривать в любом текстовом редакторе, знаки табуляции не везде корректно отобразятся и произойдет сдвиг секции кода, не выделенного операторами начала и конца кода. Попробуйте в Delphi использовать табуляцию в оболочке и потом откройте код в блокноте. Думаю, после этого вы согласитесь со мной.
  8. Как продолжение п.6 - если вы используйте табуляцию для отступа - используйте только её. Если пробелы (как в Delphi зачастую), то лучше не использовать табуляции. Это сохранит однородность оформления кода и его читаемость.
  9. Придерживайтесь одного стиля именования методов, полей, свойств классов. Это относится и к выбору языка именования: либо английский, либо уже транслитерация вашего языка.
  10. В коде не нужно писать комментарии к каждой строке. Я разделяю мнение М.Фаулера, который считает, что код, нуждающийся в комментариях - это код, который нуждается в рефакторинге. Код должен быть понятен с первого взгляда.
  11. Код не должен быть очень подробным и там, где возможно, нужно производить свертку кода.
  12. Повторяющийся код должен быть оформлен в виде методов (функций, процедур и т.д.). В этом одна из основ рефакторинга.
  13. Имена методов, свойств и полей должны быть информативны и однозначны в понимании их функционала.
  14. К методам, полям, свойствам должны быть комментарии. Это нужно для того, чтобы собранный в библиотеку класс мог иметь XML-описание.
  15. Код, как ни лениво вам их писать, должен иметь тесты, которые позволят вам же не запутаться в коде, пока вы не выполнили рефакторинг кода. Заодно, тесты помогают понять, как работает код. Когда вы поставляете библиотеку вашей команде, ваш коллега должен быстро понять, как должна работать ваша библиотека.

Желаю хорошего кодинга!

Последнее обновление ( 13.07.2009 )
 
< Пред.   След. >