Классы

[Mind]

Пирешел на классы вместо структур.Вроде все получаеться но компилятор ругаеться вот на такую вещь:

class Camera
{
public:
...
...
...
}

class Object
{
public:
...
...
...
}

void MovedCamera(Camera& CAMERA);
void CollisionsObjToCam(Object& MODEL,Camera& CAMERA);

void MovedCamera(Camera& CAMERA);
void CollisionsObjToCam(Object& MODEL,Camera& CAMERA);

Ругаеться на эти строки что идентификатор неопределен.

А когда так:

class Camera
{
public:
...
...
...
}

void MovedCamera(Camera& CAMERA);

class Object
{
public:
...
...
...
}


void CollisionsObjToCam(Object& MODEL,Camera& CAMERA);

то только на эту:

void CollisionsObjToCam(Object& MODEL,Camera& CAMERA);

Что мои кривые руки сделали не так?

Извиняюсь понял ошибку.

Мои кривые руки оказываеться создавали прототип прямо в классе(он такой большой что я не заметил его конец и создал прототп в нём )

[moka]

Ещё пометка, относительно имёнований. Классы и функции - Ок, используется BumpyCase (каждое слово с заглавное), но вот имена параметров в функциях, все заглавные, а это сильно сбивает.
Самое распространённое это использовать camelCase (когда все кроме первого слова, с заглавной). Это помогает определить тип субъекта при чтении.
Все заглавные, используются для констант (статичные значения, объявленные при компиляции).

Так пометка..

[Mind]

Ясно спасибо.Когдато раньше читл про Венгерскую систепу писания/кодинга уже подзабыл

[Mr_F_]

Ясно спасибо.Когдато раньше читл про Венгерскую систепу писания/кодинга уже подзабыл

я против венгерской.
согласен с этим чуваком:
http://insidecpp.ru/art/23/

camelCase

люблю так делать для переменных.
Но функции почему-то люблю когда с большой (ностальгия по блицу?).

[den]

Я тоже против. Только делаю одно исключение: в начале имён интерфейсов ставлю I.
IWindow напиример.

[HolyDel]

Только делаю одно исключение: в начале имён интерфейсов ставлю I.

а я не ставлю
пользователю все равно отдаются только интерфейсы. а чо там в реализации внутри либки как то пофигу.

[falcon]

Mr_F_ я против венгерской.

а ты когда нибудь копашился в огромном (действительно крупном) проекте, с тысячями и тысячами(!) файлов исходников на несколько гигов, с огромными классами, где каждая функция размером не меньше полэкрана, а в среднем с экран?
Не в графических движках или игре, устройство которых скорее всего (ну я надеюсь) ты как то понимаешь, а в том коде, работу которого ты понимаешь лишь отдалённо?
И не факт что ты проработаешь с этим кодом всю жизнь. Возможно тебя переведут в другой проект (и вполне возможно, что он окажется крупней и опять никак не связан с тем что ты более или менее знаешь). И времени изучать досконально как там всё НА САМОМ ДЕЛЕ работает ну просто не может быть.
Тебе дали задачу и сказали, что вся документация - код.
А когда функция разворачивается на экран, и не факт что именно она корень зла, да ещё и код написан по индусячьи, а задачу надо как то решить, без "вшитых" в имена данных обойтись становится на порядок сложнее. Разобрать откуда взялся тут этот указатель, инстантули его через какой то синглтон, передали в параметре, или он вообще член класса - пойди разбери если это было хрен пойми где сделано.
По поводу "плохой архитектуры" всё вода. Нельзя идеально спроектировать систему. Да даже идеальная система разрастаясь становится трудно читабельной.
Настоящая разработка ПО сильно отличается от домашней кухни. Все эти академические красоты, однозначности и мечты об идеальной архитектуре оче быстро накрываются, а примитивные префиксы обретают особую роль, когда одним мимолётным взглядом на переменную можно определить относится ли она к тому, что ты ищещ.
А все эти ошибки, которые может допустить кодер, случайно не так обозвав переменную, быстро детектятся на ревью.

[.Squid]

Сообщение от falcon

огромными классами

Сообщение от falcon

каждая функция размером не меньше полэкрана, а в среднем с экран

Сообщение от falcon

вся документация - код.

Сообщение от falcon

код написан по индусячьи

Такие ошибки не через год всплывают, они накапливаются как снежный ком с самого начала. Лид программер за зря получает повышенную з/п, если не может заставить подчиненных писать нормальный код. Венгерской нотацией тут не можешь и нельзя было помочь. Изначально все пошло не так.

[Mr_F_]

я бы не стал уж точно доверять названиям переменных, если код вышеописанный. я бы все равно проверял какой у них на самом деле тип, иначе был бы не застрахован.

[ISergey]

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

Может не будем преувеличивать...

[falcon]

Может не будем преувеличивать...

это не преувеличение, а вполне рядовая работа.

я бы не стал уж точно доверять названиям переменных, если код вышеописанный. я бы все равно проверял какой у них на самом деле тип, иначе был бы не застрахован.

доверять и нельзя. Но поверь, если ты бросишься самостоятельно проверять, что где и как, ты не найдёшь ни одного дефекта)
ну по крайней мере в течение месяца.

Такие ошибки не через год всплывают, они накапливаются как снежный ком с самого начала. Лид программер за зря получает повышенную з/п, если не может заставить подчиненных писать нормальный код. Венгерской нотацией тут не можешь и нельзя была помочь. Изначально все пошло не так.

так и есть. Ошибки всплывают сразу, и фиксятся по мере поступления. Тим лиды тут правда мало виноваты. Проект не всегда ведётся одной командой с добросовесным лидом. Тут проблема скорее менеджмента. Какой-то мудак решил сэкономить отдав код индуской организации, которая сделает быстро и дёшево. Естетсвенно у тех нету времени, кадров и квалификации для качественного ревью (в моём проекте не смотря на строгий гайдлайн, куда не плюнь видны нарушения..).
Тем не менее с этим ПРИХОДИТСЯ работать. Менеджер не понял, что отдать индусам проект - ложная экономия (ибо потом придётся потратить в трое больше времени на багофикс), но повлиять на это рядовой програмер никак не может и результат остаётся исключительно на совести управляющего.
Потому всякие мелочи в нотации действительно очень помогают. Да, им нb в коем случае нельзя всецело доверять, но тем не менее они становятся главным ориентиром при первичном анализе кода. Даже если при именовании кто-то ошибся, во всех остальных местах шансы разобраться в коде значительно повышаются.

[.Squid]

Я не понимаю. Ты хочешь сказать, что не смотря на всю задницу, в которую превратился код, венгерская нотация делает ее приятнее? Ок.

[falcon]

Я не понимаю. Ты хочешь сказать, что не смотря на всю задницу, в которую превратился код, венгерская нотация делает ее приятнее? Ок.

именно
если б в нотации не было подсказок какое говно из какого выростает, разобраться в этом всё было бы на порядок сложнее.
Сама по себе нотация код хуже НЕ ДЕЛАЕТ.

[moka]

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

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

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

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

Сама по себе нотация код хуже НЕ ДЕЛАЕТ.

Это как посмотреть, качество кода определяется по разным факторам, и одним из них являются правила написания кода, следственно влияет.

[den]

Сама по себе нотация код хуже НЕ ДЕЛАЕТ.

но и лучше тоже.