Вы можете также воспользоваться инструментом N D o c с открытым кодом ( h t t p : / / n d o c . s o u r c e f o r g e . n e t ) и автоматически сгенерировать привлекательную документацию в стиле Visual Studio на основании ваших XML-комментариев.
Комментируйте код, но делайте комментарии значимыми. Хороший комментарий рассказывает о ваших намерениях и назначении кода, а не о механике их реализации. Например, не пишите так:
/ / |
Ц и к л п о м а с с и в у с т у д е н т о в с в ы з о в о м м е т о д а D i s p l a y для |
/ / к а ж д о г о о б ъ е к т а т и п а S t u d e n t . |
Вместо этого достаточно написать: |
/ / |
В ы в о д и н ф о р м а ц и и о с т у д е н т а х . |
Посмотрите на имена методов или классов, которые собираетесь комментировать, и подумайте, нельзя ли их переименовать так, что бы комментарии стали излишни. Метод D i s p l a y A l l S t u d e n t s () не требует никаких комментариев.
Используйте хорошие описывающие имена для переменных, методов, классов и прочих объектов. Начинайте имена методов с глаголов ( D i s p l a y A l l S t u d e n t s ()), логические переменные или методы со слов наподобие is или has ( i s V a l i d , h a s l t e m s , c a n P a s t e ) , и делайте все име на понятными и значащими. Не используйте слишком длинных имен. Избе гайте применения в именах аббревиатур, в особенности нестандартных.
Хотя в этой книге и используется венгерская нотация (см. главу 3, "Объявление переменных-значений"), существуют и другие соглаше ния по именованию. Большинство программистов не используют венгер скую нотацию, в которой в качестве префикса применяется указание типа (наподобие s для s t r i n g , d для d o u b l e и так далее). В предыдущем примере использован другой стиль именования, который вы встречаете в большей части документации и примеров.
Пишите короткие методы, которые проще для понимания, менее подвер жены ошибкам и легче тестируются. Везде, где это возможно, работа метода должна использовать вызовы других методов. Это называется разложением вашего кода. Если категорически не требуется иного, делайте ваши методы за крытыми. Даже однострочный код стоит выделить в отдельный метод, если это делает код исходного метода понятнее. Предположим, например, что у вас есть сложное составное логическое выражение, наподобие
i f ( ( y p o s = = - 1 ) & ( v o w e l P o s = = - 1 ) ) . . .
Его достаточно сложно понять с первого взгляда. Можно использовать комментарии для пояснения сути дела, но маленький метод с хорошим именем ничуть не хуже:
p u b l i c b o o l H a s N o V o w e l s ( i n t |
i n d e x O f L e t t e r Y , |
i n t |
i n d e x O f F i r s t V o w e l ) |
{
r e t u r n ( i n d e x O f L e t t e r Y = = - 1 ) &
( i n d e x O f F i r s t V o w e l = = - 1 ) ;
}