Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, ononim, Вы писали:
O>>вместо x/y/width/height стали юзать left/top/right/bottom?
К>вместо x/y стали юзать TOP / LEFT. К>а вместо width/height — vertical/horizontal, соответственно
Да, как тут когда-то писали — это неполиткорректно. Правильно dimension1, dimension2...
Здравствуйте, ononim, Вы писали:
D>>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет. D>>Николай, не очень понял O>Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Кодт, Вы писали: К>>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия... __>подчеркивания в членах класса — фуу
Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
Здравствуйте, Dair, Вы писали: D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
разумеется. просто предпочитаю не иметь чего-то, чем иметь что-то лишнее, непонятно зачем нужное. а то попахивает "C" перед именами классов
Здравствуйте, __kot2, Вы писали:
__>ну и сама реализация класса тоже спорная. я бы лично оставил x и y публичными, чем городить геттеры-сеттеры к ним
У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
А если всё через геттер — то это единообразие.
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, __kot2, Вы писали: __>>подчеркивания в членах класса — фуу
D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
Здравствуйте, Кодт, Вы писали: К>У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
тогда логично хранить {left,top,right,bottom} и иметь методы width() и height()
К>А если всё через геттер — то это единообразие.
все сделано через геттеры
Здравствуйте, Marty, Вы писали: M>Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет
правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Здравствуйте, __kot2, Вы писали:
__>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
Здравствуйте, Marty, Вы писали: __>>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров M>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
во-во, я и говорю — самые упоротые
вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным
Здравствуйте, CreatorCray, Вы писали: __>>>подчеркивания в членах класса — фуу Ops>>ну уж не хуже m_ CC>Если на то пошло то m_ лучше чем просто подчёркивание.
все это разговоры про сорта говна. никакие префиксы не делают код читабельней. они появляются тогда, когда человек открывает для себя новую концепцию — клссов, интерфейсов или приватных членов и начинает везде пихать поначалу
Здравствуйте, __kot2, Вы писали:
__>все это разговоры про сорта говна. никакие префиксы не делают код читабельней.
Таки делает, если употреблять разумно.
В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную.
Это единственный случай когда префикс приемлем.
Как только сделают хорошую схему для syntax highlighting которая бы этот вопрос качественно решала без превращения кода в цветомузыку — это применение тоже отсохнет естественным путём.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: CC>В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную.
с учетом того, что большая часть кода работает именно с локальными переменными, имело бы смысл делать префикс скоре не для них, а то весь код в префиксах получается. но все же понимают, что это изврат, потому что без классов такого не было.
вот и решили ввести подчеркивания для приватных.
CC>Как только сделают хорошую схему для syntax highlighting которая бы этот вопрос качественно решала без превращения кода в цветомузыку — это применение тоже отсохнет естественным путём.
у С++ есть одно прекрасное свойство — можно любой обьект вернуть как const и он будет только для чтения разумеется.
не вижу никакой разницы — вызывать p.x() или читать напрямую p.x из const Point &p;
нафиг тогда вообзе p.x() нужен? единственный случай — есть какой-то шаблонный код, который всегда вызывает именно p.x(), который для некоторых обьектов вычисляется. но я не думаю, что это по этой причине сделано.
людям, пришедшим из явы-C# это концепция дается с трудом, но все-таки надо же пользоваться именно инструментами языка, а не писать в стиле другого
вообще, на самом деле к оечно придирабс и хромиум — один из лучших проектов на С++. есть такой мрак, что прямо кровь из глаз течет и ничего — пользуются люди. но если придираться, то я мое ревью бы на Point.h выглядело бы так:
constexpr Point() : x_(0), y_(0) {} - нафиг constexpr. что он дает?
constexpr Point(int x, int y) : x_(x), y_(y) {} - зачем два конструктора, когда одного достаточно с дефолтными параметрами?
constexpr int x() const { return x_; } - убрать нафиг эти методы, сделать члены x и y публичными
constexpr int y() const { return y_; }
void set_x(int x) { x_ = x; } - наркомания!
void set_y(int y) { y_ = y; }
void SetPoint(int x, int y) { - тяжелая наркомания! зачем нужен метод копирующий реализацию конструктора? почему не p = Point(10, 20), зачем вообще нужен этот set?
x_ = x;
y_ = y;
}
почему паскалевское именование в С++ проекте?
void SetToMin(const Point& other); - непонятная фигня. почему это метод класса Point?
std::string ToString() const; - почему это метод класса а не статич ф-ия?
Здравствуйте, Ops, Вы писали:
AD>>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left) Ops>А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.
Здравствуйте, __kot2, Вы писали:
CC>>В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную. __>с учетом того, что большая часть кода работает именно с локальными переменными, имело бы смысл делать префикс скоре не для них, а то весь код в префиксах получается.
Ну так и получается. Все локальные (параметры функции — локальные) без префикса, любые мемберы с m_, статики s_, глобальные g_. Больше никаких префиксов не надо.
__>вот и решили ввести подчеркивания для приватных.
ИМХО это как то буэ. Какая разница приватный или паблик? У них разные контейнеры, это как раз и важно видеть.
__>у С++ есть одно прекрасное свойство — можно любой обьект вернуть как const и он будет только для чтения разумеется. __>не вижу никакой разницы — вызывать p.x() или читать напрямую p.x из const Point &p;
Потому что далеко не всегда у тебя есть исключительно const ссылка на объект, и тогда в том месте можно в p.x ещё и писать, что может вызвать совсем не тот эффект, который ожидался. Получается дыра в интерфейсе через которую можно внутрях всё испортить.
Так что нет.
__>людям, пришедшим из явы-C# это концепция дается с трудом, но все-таки надо же пользоваться именно инструментами языка, а не писать в стиле другого
в жабашарпах есть синтаксическая сахарная нашлёпка, называется property. Это автоматически создаваемый getter + setter, который можно переопределить.
__>constexpr Point() : x_(0), y_(0) {} — нафиг constexpr. что он дает?
Мне кстати тоже непонятно.
__> constexpr Point(int x, int y) : x_(x), y_(y) {} — зачем два конструктора, когда одного достаточно с дефолтными параметрами?
Спорно, ну да ладно. Тут скорее вопрос стилистики, единообразия интерфейсов и чистоты кода в более сложных случаях чем этот.
__> constexpr int x() const { return x_; } — убрать нафиг эти методы, сделать члены x и y публичными __> constexpr int y() const { return y_; }
Категорически нет.
Публичные поля в классе — один из признаков говнокода. Хочешь публичные поля — определяй struct.
__> void set_x(int x) { x_ = x; } — наркомания! __> void set_y(int y) { y_ = y; }
Нет.
__> void SetPoint(int x, int y) { — тяжелая наркомания! зачем нужен метод копирующий реализацию конструктора? почему не p = Point(10, 20), зачем вообще нужен этот set? __> x_ = x; __> y_ = y; __> }
Для простого класса с POD типами да, разницы никакой, для более тяжёлых разница начинает появляться. Если стоит задача придерживаться единой стилистики интерфейсов для базовых классов, к которым этот явно относится, то лучше делать единообразно — компилятор потом всё заинлайнит всё равно.
__>почему паскалевское именование в С++ проекте?
А какая компилятору разница?
Что и как называть определяется принятым в команде coding standard.
__> void SetToMin(const Point& other); — непонятная фигня. почему это метод класса Point?
А почему нет? Что оно делает внутри?
__> std::string ToString() const; — почему это метод класса а не статич ф-ия?
А почему это должна быть статическая функция? Её ж пользовать неудобно.
Если чо, это вообще могло бы быть operator std::string () const;
Вообще ветку пора в срачи переносить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Перекуём баги на фичи!
