Гуляя нашел такую статью Как заставить неправильный код выглядеть неправильно от дядьки Joel'a. 
Очень неплохого, кстати дядьки и статьи у него всегда интересные.

Но суть не в этом. В предложенной им статье показывается что существует две Венгерских нотации - Прикладная и Системная. Первая появилась раньше и была "правильной", вторая позже и является той, которую мы имеем в виду говоря про эту нотацию. А суть такова, что в прикладной нотации предлагается давать переменным префиксы, которые отражали бы содержимое переменных, а не их ТИП, как это делается в системной нотации. Кроме того, префиксирование касается не только переменных, но и имен функций. И даже их именований, как например, стандартное TypeToType рекомендуется заменить на TypeFromType, т.к. тип результата при таком раскладе будет находиться слева, что ближе к присваиванию и потому более понятно.
В статье приводится пара интересных примеров. И в конце несколько мутная добавка про обработку исключений.

Для меня эта статья явилась неожиданной. Я, конечно, и раньше изредка давал переменным функциональные префиксы, но далеко не всегда и действуя скорее для облегчения читабельности (и не только! венгерская нотация способна уберечь от ошибок!) какого-то локально участка кода, теперь, пожалуй, буду примерять ее повсеместно.

Скажите, что вы об этом думаете? Используете ли вы префиксы в именовании переменных?
если не в тот форум, направьте меня на путь истинный

Это сообщение отредактировал(а) Alix - 15.10.2007, 17:51

Интересная статья. Спасибо.

Было многабукв, здохли два раза - после возврата из предварительного просмотра и открытия смайликов (IE 6.0)

Вкратце - все зависит от:

• языка программирования - ООП языки, хоть и не радуют автора статьи своей (кажущейся) сложностью, однако способны избавить от методов длинной несколько страниц, разгрузить проблемы архитектурой - складывая i+j вам не нужно знать как это работает если это работает, печать также может быть определена и все это только начало 
• библиотек - Qt не использует префиксы, Symbian - своя система;
• контекста - суть кода должна быть ясна.

Я использую C++ с ООП, паттернами и рефакторингом:

• m_ для полей класса;
• без префикса для полей структуры;
• i, dw, lpcstr - не использую - многабукв;
• код должын быть понятен без комментариев;
• работа в команде - работа с единым подходом.

Рекомендую пересмотреть эту точку зрения, на ней далеко не уехать.

Не осилил. ИМХО, обе великих венгерских нотации - суета-сует и томленья духа. 

Shaggie
Рекомендую пересмотреть эту точку зрения, на ней далеко не уехать.
Don't comment obvious. Если нужны комментарии, это повод задуматься, почему код недостаточно понятен.

__kish
m_ для полей класса
Абсолютно, ИМХО, бессмысленное и малопродуктивное занятие.

ООП языки, хоть и не радуют автора статьи своей (кажущейся) сложностью, однако способны избавить от методов длинной несколько страниц
ИМХО никакой такой связи между ООП, классическим процедурным программированием и методами длинной в несколько страниц нет.

код должын быть понятен без комментариев
Абсолютно с вами согласен.

Комментарии помогут за пять секунд понять, что это за сложный алгоритм (какой-нибудь хитрый ацикличный перебор графа) и его предназначение в данном месте.

Комментарии помогут за пять секунд узнать, что делает конкретный метод. Не как - это видно из кода, но что. Общая картина складывается быстрее. Дебажил когда-нибудь чужой код? Сваянный тремя программерами последовательно и ещё двумя параллельно?

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

Комментарии есть часть технической документации на программное обеспечение.

С помощью комментариев можно писать аннотации (кто знает Java - меня поймёт).

Короче говоря комментарии - это могучий инструмент экономии времени программиста.

Shaggie
Комментарии помогут за пять секунд понять, что это за сложный алгоритм (какой-нибудь хитрый ацикличный перебор графа) и его предназначение в данном месте. Комментарии помогут за пять секунд узнать, что делает конкретный метод. Не как - это видно из кода, но что. Общая картина складывается быстрее.
Согласен, что в какой-то мере понять помогут. За 5 секунд - вряд ли. Тем не менее практически не видел дельных комментариев ни в коммерческом коде, ни в open source. Ценность же комментирования банальных вещей практически равна нулю.

Дебажил когда-нибудь чужой код? Сваянный тремя программерами последовательно и ещё двумя параллельно?
Отлаживал.

Комментарии помогут быстро вспомнить, что делает эта нелепая конструкция в написанном тобой год назад коде. Поверь, на эти грабли натыкается каждый программист.
А зачем, собственно, писать эти нелепые конструкции? Чтобы потом писать пространные комментарии?

Комментарии есть часть технической документации на программное обеспечение.
Не обязательно.

Короче говоря комментарии - это могучий инструмент экономии времени программиста.
Где конкретно происходит эта экономия?

что только люди не придумают, чтобы не писать комментарии. 

Во многих случаях имена передаваемых параметров совпадают с именами полей класса. Может это архитектуру кривую делаю 


Облажался - избавить может хорошая архитектура :-[


Локальные переменные с именами row, col как раз показывают это утверждение в коде. Ну а префикс, в данном контексте, является комментарием к каждому применению переменной...


Вот и будет он в Graph::HitriyAnticiklichniyPerebor(...) 


Абсолютно согласен. Использую Doxygen, обычно достаточно комментирования класса, реже - методов, но комменты внутри метода  говорят что перед Вами мрак - автоматом можно приписывать wtf.