parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Сколько вешать в граммах?

AleXp 04.10.2005 15:06 / 04.10.2005 15:18

Насчет комментариев - спор не предметный, на мой взгляд. Все зависит от ситуации. Т.е.:

посностью согласен, но вы пишите код на парсере. код, который в общем случае не должен быть предназначен для тех, кто в глаза не видел его. т.е. человек, который его будет читать знает его.
поэтому комментировать:
# Если входной hash определен...
^if(def $arrHash){
есть бред. из базового оператора понятно что он делает, и подобные комментарии только усложняют жизнь.


Я подразумеваю, что на кодах опубликованных на сайте www.parser.ru - УЧАТСЯ! Т.е. не столько используют в своих работах, сколько изучают "правильный" и красивый код и привыкают "мыслить в унисон". Посему и такое мое отношение к комментариям. Если речь идет только об использовании готовой библиотеки, то тогда и отступы при написании кода надо убрать, и переносы строк лишние. Зачем? Работать будет и без этих украшательств. А уж если кто-то решил менять в коде строчки, так пусть первым делом удалит лишние комментарии и вставит свои - без этого действительно запутаться и потеряться легко, особенно если "почерк" размещения комментариев совпадает:
# Это комментарии мои
...
# А это комментарии Василия Пупкина
...
Про классы...

предположим вы написали какую-нить CMS ли ещё что. потом вы пошли в отпуск, и срочно потребовалось внести несколько однотипных изменений. вместо вас кто-либо рассудив "раз они однотипные, добавлю-ка один оператор (метод MAIN) @announce[] и вызову его несколько раз". добавил. вызвал. проверил - вроде все ок...

CMS, опять-таки по моему разумению, на 90% должна состоять из документации в которой, в том числе и как минимум, должны быть описаны все классы, функции API, операторы, методы, переменные и т.п. и т.д. (имеется в виду контекст разработчиков, а не секретарш - для них API не надо!). Если это есть, то имея на руках эту документацию влезть в чужой код и задублировать оператор @announce[] может только человек который характеризуется поговоркой про сдуру сломанный <сам знаешь что>. Такой все равно что-то да сломает. А вот если документации нет, то это не CMS, а код для частного использования и в него нефиг лазать кому-либо постороннему.

В общем: вернулись к вопросу о документировании кода ;)

И это... Из библиотеки класс делается в два удара:

1. Добавим в начале файла visualization.p строки
@CLASS
vizualization
2. Добавим в твой lib.p метод
@debugShowObject[object]
^visualization:debugShowObject[$object]
#end @debugShowObject[]
Всего делов-то. Во всех остальных местах всей системы ничего больше менять не надо. Было бы о чем спорить ;)

Вешать то будем? :)