Классы
Пирешел на классы вместо структур.Вроде все получаеться но компилятор ругаеться вот на такую вещь:
Код:
class Camera Цитата:
А когда так: Код:
class Camera Цитата:
Извиняюсь понял ошибку. |
Ответ: Классы
Ещё пометка, относительно имёнований. Классы и функции - Ок, используется BumpyCase (каждое слово с заглавное), но вот имена параметров в функциях, все заглавные, а это сильно сбивает.
Самое распространённое это использовать camelCase (когда все кроме первого слова, с заглавной). Это помогает определить тип субъекта при чтении. Все заглавные, используются для констант (статичные значения, объявленные при компиляции). Так пометка.. |
Ответ: Классы
Ясно спасибо.Когдато раньше читл про Венгерскую систепу писания/кодинга уже подзабыл :)
|
Ответ: Классы
Цитата:
согласен с этим чуваком: http://insidecpp.ru/art/23/ Цитата:
Но функции почему-то люблю когда с большой (ностальгия по блицу?). |
Ответ: Классы
Я тоже против. Только делаю одно исключение: в начале имён интерфейсов ставлю I.
IWindow напиример. |
Ответ: Классы
Цитата:
пользователю все равно отдаются только интерфейсы. а чо там в реализации внутри либки как то пофигу. |
Ответ: Классы
Цитата:
Не в графических движках или игре, устройство которых скорее всего (ну я надеюсь) ты как то понимаешь, а в том коде, работу которого ты понимаешь лишь отдалённо? И не факт что ты проработаешь с этим кодом всю жизнь. Возможно тебя переведут в другой проект (и вполне возможно, что он окажется крупней и опять никак не связан с тем что ты более или менее знаешь). И времени изучать досконально как там всё НА САМОМ ДЕЛЕ работает ну просто не может быть. Тебе дали задачу и сказали, что вся документация - код. А когда функция разворачивается на экран, и не факт что именно она корень зла, да ещё и код написан по индусячьи, а задачу надо как то решить, без "вшитых" в имена данных обойтись становится на порядок сложнее. Разобрать откуда взялся тут этот указатель, инстантули его через какой то синглтон, передали в параметре, или он вообще член класса - пойди разбери если это было хрен пойми где сделано. По поводу "плохой архитектуры" всё вода. Нельзя идеально спроектировать систему. Да даже идеальная система разрастаясь становится трудно читабельной. Настоящая разработка ПО сильно отличается от домашней кухни. Все эти академические красоты, однозначности и мечты об идеальной архитектуре оче быстро накрываются, а примитивные префиксы обретают особую роль, когда одним мимолётным взглядом на переменную можно определить относится ли она к тому, что ты ищещ. А все эти ошибки, которые может допустить кодер, случайно не так обозвав переменную, быстро детектятся на ревью. |
Ответ: Классы
Цитата:
Цитата:
Цитата:
Цитата:
|
Ответ: Классы
я бы не стал уж точно доверять названиям переменных, если код вышеописанный. я бы все равно проверял какой у них на самом деле тип, иначе был бы не застрахован.
|
Ответ: Классы
Цитата:
|
Ответ: Классы
Цитата:
Цитата:
ну по крайней мере в течение месяца. Цитата:
Тем не менее с этим ПРИХОДИТСЯ работать. Менеджер не понял, что отдать индусам проект - ложная экономия (ибо потом придётся потратить в трое больше времени на багофикс), но повлиять на это рядовой програмер никак не может и результат остаётся исключительно на совести управляющего. Потому всякие мелочи в нотации действительно очень помогают. Да, им нb в коем случае нельзя всецело доверять, но тем не менее они становятся главным ориентиром при первичном анализе кода. Даже если при именовании кто-то ошибся, во всех остальных местах шансы разобраться в коде значительно повышаются. |
Ответ: Классы
Я не понимаю. Ты хочешь сказать, что не смотря на всю задницу, в которую превратился код, венгерская нотация делает ее приятнее? Ок.
|
Ответ: Классы
Цитата:
если б в нотации не было подсказок какое говно из какого выростает, разобраться в этом всё было бы на порядок сложнее. Сама по себе нотация код хуже НЕ ДЕЛАЕТ. |
Ответ: Классы
Даже MS открыто говорят о непригодности венгерской нотации в современном коде.
Я лично, нигде в нормальных компаниях не встречал этого. Было пару раз лишь, одна была - индусский оутсорс, да и там больше инженеры (микроконтроллеров) писали код, а они это делали то как их там учили, а это было давно. Другой раз, какой-то самоучка, с ним было тяжело общаться вообще, само убеждённый и наивный.. В том же классе, придерживаюсь таких правил: 1. camelCase - для всех переменных, локальных, параметров, мемберов (никаких _ вначале). 2. BumpyCase - для наименований классов, объеденений, методов, аксессоров. Это помогает иметь например приватный фиелд в классе "name" и аксессор к нему "Name". Удобно и читаемо. 3. Если обращаюсь к фиелдам экземпляра класса, то всегда использу "this." вначале. Угу, кто-то подумает много читать, но я предлагал данную коррекцию в написании многих разрабов, и показывал примеры, 90% соглашались, и в итоге также задумывались об использовании. Дело в том чтобы чётко разделить границу между именно локальными переменами и теми что являются фиелдами класса. В Венгерской Нотации, это решалось "_" в начале локальной переменной. Но это имхо некрасиво, да и читабельность страдает. А с хорошей подсветкой "this." - выглядит куда информативнее. Зачем? А затем что в метод можно передать параметр: BlaBla(string name) {, учитывая что и фиелд класса которому принадлежит метод, может иметь то же самое имя "name", и чтобы не напортачить, всегда обращаемся через this. или без. Это сразу отделяет эти две переменные с одним именем. .Squid +1, насчёт "убер функций" и т.п., что это проблема самой организации работы и философии. Что тут сказать, если нада с таким работать, то мне вас лично жалко, т.к. это ужас с таким работать. Класс должен делать только свою работу, а методы маленькими и выполнять конкретную задачу, а не кучу процессов, где как раз и заключается проблема. Код с функциями во весь экран - есть зло. Цитата:
|
Ответ: Классы
Цитата:
|
Часовой пояс GMT +4, время: 01:46. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot