Тема: Классы
Показать сообщение отдельно
Старый 01.09.2011, 13:58   #14
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Классы

Даже MS открыто говорят о непригодности венгерской нотации в современном коде.

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

В том же классе, придерживаюсь таких правил:
1. camelCase - для всех переменных, локальных, параметров, мемберов (никаких _ вначале).
2. BumpyCase - для наименований классов, объеденений, методов, аксессоров. Это помогает иметь например приватный фиелд в классе "name" и аксессор к нему "Name". Удобно и читаемо.
3. Если обращаюсь к фиелдам экземпляра класса, то всегда использу "this." вначале. Угу, кто-то подумает много читать, но я предлагал данную коррекцию в написании многих разрабов, и показывал примеры, 90% соглашались, и в итоге также задумывались об использовании. Дело в том чтобы чётко разделить границу между именно локальными переменами и теми что являются фиелдами класса. В Венгерской Нотации, это решалось "_" в начале локальной переменной. Но это имхо некрасиво, да и читабельность страдает. А с хорошей подсветкой "this." - выглядит куда информативнее.
Зачем? А затем что в метод можно передать параметр: BlaBla(string name) {, учитывая что и фиелд класса которому принадлежит метод, может иметь то же самое имя "name", и чтобы не напортачить, всегда обращаемся через this. или без. Это сразу отделяет эти две переменные с одним именем.

.Squid +1, насчёт "убер функций" и т.п., что это проблема самой организации работы и философии.
Что тут сказать, если нада с таким работать, то мне вас лично жалко, т.к. это ужас с таким работать.
Класс должен делать только свою работу, а методы маленькими и выполнять конкретную задачу, а не кучу процессов, где как раз и заключается проблема.
Код с функциями во весь экран - есть зло.

Сама по себе нотация код хуже НЕ ДЕЛАЕТ.
Это как посмотреть, качество кода определяется по разным факторам, и одним из них являются правила написания кода, следственно влияет.
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Mr_F_ (01.09.2011)