parser

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

 

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

Ответ

Misha v.3 30.08.2006 12:40

Два пробела -- это для того, чтобы удобно было при беглом просмотре кода
для начала я не знаю для чего нужен "беглый просмотр кода". искать методы? у меня есть их список перед глазами и Ctrl+F.

это - способ форматирования, который обычно применяется при ином способе форматирования операторов подробности см. в книге "Совершенный код".
в случае parser я считаю его применение не очень удобным, т.к.
мы имеем дело с интерпретируемым языком, каждый символ которого попадает в результирующий код (и лишь затем удаляется). добавлять XYZ символов, тратя память и время (загрузка файлов) - роскошь, в то время как можно воспользоваться лишь немного иным способом форматирования (который кстати тоже достаточно распространен)
Пробелы вместо табов -- у разных людей табы выглядят по разному, это не очень приятно.
меня не интересует как будет выглядеть код у людей, которые не могут настроить свой редактор чтобы им было удобно читать его. и лишь совсем простые редакторы не позволяют задать способ отображения табов.
и опять-же это - увеличивает размер файлов, которые грузятся при каждом обращении и потом выкидываются.
Символ подчеркивания в локальных переменных -- объясните, почему?
у меня в методе обычно 1-2 параметра, и пачка локальных переменных. наблюдаю сплошные $_xyz... это напрягает да и целесообразность не понятна.
Отсутствие префикса типа. Я сделал постфикс. Префикс действительно лучше???
не знаю, не использовал.
я с трудом представляю себе понятность кода при использовании _коротких_ суффиксов (вы это имели ввижу под "постфиксом"?), а длинные (как например ваш Hash) я использовать не хочу (см. выше про размер кода).
у меня в настоящий момент так: tUser, hUser, sText, dtDate, bPublished, iCount, dCurrency и т.д. придумал не я. взял на вооружение у кого-то в студии. вначале было неудобно, сейчас очень нравится (соотв. можете видеть что в классах, которые я обновляю в примерах внедряется этот стиль именования). ну и очевидно, что никаких безтиповых temp используемых в одном методе для хранения разных типов данных.

да, забыл... бывает ещё префикс 'u' - unknown, это когда например метод может принять и переварить разные типы данных.
Избыточные комментарии требуются внутри продуктов 8azion.
_избыточные_ комментарии вредны. это хуже чем их отсутствие [(c) Любая книжка]. через некоторое время жизни кода они становятся не актуальными. их актуальность никто и никогда не поддерживает. нужно писать понятный код, а не "комментировать всякий свой поступок". естественно у меня нет больших возражений по поводу комментариев для классов/методов и тех мест где они действительно нужны. однако для интерпретируемого языка стоит стараться сокращать их количество.
Ограничение на длину строки -- для того, чтобы код не вылезал за рамки.
мы имеем дело с языком у которого нет оператора print. для того чтобы не добавлять в результирующий код ненужные пробельные символы иногда мы вынуждены писать длинные строки (я стараюсь их не писать, тем не менее приходится). кроме того работая в разрешении 1280*1024 видеть лишь узкую колонку кода из 80 символов я не согласен (даже с учетом дополнительной панели функций у меня влазит 120 символов. почему я должен не использовать треть рабочего пространства?). а чтобы код не вылезал я умею использовать функцию Word Wrap моего редактора.
В конце концов, это стандарты для 8azion. А для остальных -- лишь рекоммендации.
дык я и не говорил что всё это полное гавно, я сказал лишь что мне с этими стандартами не по пути :)