Пытался пользоваться группами вкладок в Firefox.
В итоге, мне удобней открывать несколько окон, да и переключиться можно быстро.
А вообще, стараюсь не держать много открытых вкладок.
По личному опыту, проходит 2-3-4-7 дней, а они всё висят и висят.
В итоге их просто закрываешь, даже не читая, что там.
Как правило, открыл вкладку, прочитал, закрыл.
Проверил — в Firefox тоже работают пункты 1, 2, 3.
Пункт 4 «барахлит».
Сейчас решил попробовать случайные кнопки (поэксперементировать), чтобы выделить текст ссылки в Firefox.
Как-то быстро прошёл эксперимент.
Если зажать ALT и выделять текст, то текст будет выделяться, а не перетаскиваться.
И чего я раньше не пытался это проверить — столько лет мучений…
Про выделение текста – в точку (как просто текста, так и текста внутри ссылок).
В старой Opera мне нравилось то, что некоторые «хакерские» JS события/действия и CSS хаки не работали.
В частности, onunload, или oncontextmenu, или user-select:none;
Конечно, иногда это было и минусом, но банальный пункт «Разрешить на этом сайте все события» решил бы проблему.
Сейчас какая-то странная тенденция…
Вместо работы над «полезностью» пытаются внести изменения в дизайн (расположение вкладок, кнопок и т.п.).
В последнем Firefox'е вообще из меню пропал пункт «Загрузки».
>> они должны быть предельно просто и понятно описаны
При взгляде на примеры не понятно, что значит item — это «товар как модель каталога» или же «товар как модель корзины».
Я твёрдо считаю, что язык программирования отличается от разговорного языка.
Поэтому в нём должны быть более сухие и максимально чёткие обозначения.
Пусть они читаются не так лаконично, зато исключается всякая двусмысленность.
>> говорили на одном языке с руководством и исполнителями
Для таких разговоров, зачастую, упускаются незначительные детали, чтобы не перегружать слушателей не столь важными данными.
Например, вывод каталога с учётом остатков или отображение разных цен для разных типов клиентов.
Да и, если уж так, то более понятней для руководителя будет читать:
— Пользователь -> Корзина -> Товар -> Название
— Каталог -> Товар -> Цена
А как цена определяется, как высчитывается — это тема для отдельного разговора с отдельным описанием логики.
>> описание вашей модели данных будет не универсальным и понятным лишь узкому кругу специалистов — программистам Yii
А в чём заключается неуниверсальность?
Есть модель пользователя, есть модель корзины.
Какая бы ни была платформа для разработки, надо организовать эту связь.
То есть, в любом случае будет связь (relation), а каким образом (на уровне framework'а) она будет организована — это не имеет значения к наименованию связи.
К тому же, префиксы и постфиксы не взяты наобум.
Они, в принципе, нормально вписываются в общие правила именования.
Взять ту же модель — по аналогии с UserForm / UserValidator / UserController есть также класс UserModel.
>> которых вы посвятили в свои правила
Этот вопрос уже поднимался.
Как я думал, и как подчеркнули в комментариях — есть стандарты, которых придерживаются программисты.
И чтобы программист понимал, что и как именуется, его надо будет обучить (предоставить регламент или справку).
Пока я вижу некоторую проблему только в этом.
Да, насчёт общепринятых стандартов и обучения я тоже думал.
И в топике указал это мнение.
Только иногда проще подсунуть под нос регламент и сказать, что надо писать префиксы, нежели научить программиста писать правильный код с phpdoc'ами и нормальными конструкциями.
Это хорошо, когда программист понимает всю логику сервиса/программы/сайта и пишет так, что не надо никаких комментариев.
Но ведь это, скажем так, редкость.
Как мне кажется, в некоторых случаях проще составить один документ на 1-2 листа с регламентом именования сущностей, чем 10-20 листов, где будут перечислены все примеры, как надо писать код, а как не надо.
Причём тут «пытается всем доказать»?
Я написал статью, в которой рассказал о том, какие способы я использую для наименования сущностей в ЯП.
Вы же своим комментарием ничего толкового не сказали.
Прочитал я ваш комментарий, увидел, что вы придерживаетесь другой точки зрения.
А какой?
Где «именно конструктивного обсуждения такого подхода», о чём я просил в конце топика?
Я нисколько не обиделся, скорее, удивился, что комментаторы то и дело говорят, что это плохо, а почему — сказать явно не могут.
Лишь бы что-то написать…
1.
Да, так и есть — вношу изменения вручную.
Честно, мне не сложно дописать пару-тройку строк (атрибут в phdoc, валидацию и relation).
Не всегда требуется указывать проверку или relation, поэтому вообще одна строка.
К слову, может быть у вас такого не было, но сгенерированная через gii модель опасна.
Дело в том, что gii не понимает, какие атрибуты надо разрешить редактировать, а какие нет.
И большинство так и оставляют валидацию критически важных полей типа id, parent_id, user_id и т.п.
А затем присваивают через $_POST['ModelName'].
Думаю, если вы знаете Yii, сможете понять, где уязвимость.
2.
Это не слово паразит — это префикс.
Тут более уместней сочетания «Модель пользователя», «Модель заказа», «Внешняя связь с заказом», «Внешная связь с документом».
И это, как мне кажется, более понятней, чем пытаться объяснить собеседнику, что не «пользователь, который на сайте» или «не документ word, а документ, но к заказу, а не к доставке».
3.
Тут в большей степени дело в том, что Yii использует метод, названный model.
Если же метод был бы назван по-другому, было бы даже более понятней.
К слову, мне кажется, что NewsModel со статичными переменными/константами/методами выглядит более понятней, чем просто News.
Я уже не удивляюсь, что вы так ответили.
Я прочитал ваш первый комментарий, постарался узнать, почему вы так думаете.
Вы написали второй комментарий, из которого я тоже ничего полезного не вынес.
Не могу понять — зачем это писать?
В JS, как я написал выше, вы не сможете найти ВСЁ по ".container", так как могут встречаться, например, addClass('container') или вообще item.className = 'visible container'.
1.
Что значит — мешать в кучу?
У вас есть класс/идентификатор стиля — и вам его надо задействовать и в CSS, и в JS, и в PHP…
>> У каждого своя область использования и следовательно разные подходы к разработке.
>> То что прокатит в html в js может выйти боком.
Опять же, к чему это?
Это и так понятно.
2.
>> «умник» решивший что неплохо бы иметь перменную cl_container
Для этого есть регламент.
Хотя, на моей памяти ещё ни разу не встречалось таких переменных.
3.
Я не пытаюсь разработать стандарт для наименования.
Изначальная цель была — не придумать что-то, а спросить у сообщества, как они выходят из таких ситуаций.
Как они разделяют разные типы данных и именуют переменные.
Для себя я придумал такие вот префиксы и постфиксы.
И ожидал услышать адекватные «за» и «против».
Причём такие, чтобы я смог уверенно сказать «да, тут я не прав».
Пока я не увидел таких комментариев, хотя некоторые, замечу, дали повод задуматься.
Что тут помнить — идентификатор превыше класса.
Да и, наиболее используемых не так много.
Что касается «всё стараются завязывать на классах»…
Чем преимущество завязывания кнопки корзины на классы перед идентификатором?
Или ещё какой-нибудь блок, который уникален для сайта.
Например… блок сверху информацией о пользователе.
Я считаю, что идентификатор даёт другому программисту/дизайнеру понять, что этот элемент — единственный на сайте.
Он уникальный, и других таких нет.
А класс… он не уникальный, их много, разных, и одно и то же имя класса может использоваться для разных элементов.
Собственно, для этого изначально и предназначались идентификаторы и классы.
Про phdoc'и я знаю, и что в return писать тоже знаю.
Стараюсь максимально покрывать ими код, в том числе и внутри методов, например, когда используется switch case.
А насчёт разных объектов…
Собственно, это я и имел ввиду, когда писал, что ссылка на класс через объединение строк — это плохо.
Только, не могу понять логики минусующих/плюсующих…
Почитайте насчёт того, что такое суффикс.
Вкратце:
— Префикс — то, что идёт прежде всего — перед ним ничего нет;
— Постфикс — то, что идёт после всех частей слова — за ним уже ничего нет;
— Суффикс — то что идёт после корня, за суффиксом может быть окончание.
>> И да, в PHP такое делать, несомненно, не стоит.
Почему?
Но суть не в том, что можно регулярку в поиск указать (это я знаю).
Суть в том, что одной регуляркой тут явно не обойдёшься.
Есть же ещё JavaScript и CSS, а также PHP файлы.
И там нельзя регуляркой найти — слишком много может быть частных случаев.
Навскидку:
— addClass('container')
— $('.container').remove()
— $container.append('OK')
— container = $(this)
В итоге, всё равно надо будет открывать и анализировать каждое совпадение слова «container».
Что касается cl_container.
Поиск через регулярки нужен, чтобы провести обфускацию и сжатие.
А в работе вообще не надо никаких регулярок — вбивай в поле поиска «cl_container» — и всё, что нашлось — всё классы CSS.
1.
Я генерирую модель только один раз — изначально.
Затем уже вручную добавляю все связи и проверки.
По крайней мере мне не надо проверять, что изменилось, а что — нет.
Особенно это актуально, когда модель состоит не из 10-20 строчек по-умолчанию.
2.
Соглашусь, что префикс R и написание Rcomments — это бред, читаемость резко падает.
Но я же в топике написал не так, а R_, то есть R_Comments, R_CatalogCategory.
Неужели так сильно отличается читаемость R_Comments от comments?
3.
Про $newsModel->R_Author->name — тоже верно, читаемость не очень.
Но я ничего и не говорил про именование переменных — я писал про классы.
Более того, переменная — она локальная, и глупо добавлять постфикс Model.
Массивы я тоже не люблю — и об этом я тоже написал в своём топике.
А это тут причём?
Мне надо найти и заменить — статью кто-нибудь читает?
Вот есть класс container (приведённый в комментарии выше), и мне надо его заменить.
Я открываю форму поиска в IDE и ввожу туда слово «container».
Потом ставлю, что надо искать по файлам CSS / HTML / JS / PHP.
Вываливается 100-200 файлов.
По вашей логике, мне надо открыть все файлы и глазами пробежаться по всем совпадениям и заменить.
При этом, проанализировать, действительно ли это класс, а не что-то другое (например, не переменная JS).
Так?
Это какой у вас такой HTML в котором такое нужно?
В нашем обычном как бы и так все понятно:
Надо заменить его на что-то другое.
И как найти, где используется идентификатор «container»?
Все вьюшки, стили, JS-скрипты…
Не ясно почему легче.
Потому что есть разного рода расширения, плагины и т.п., где НЕ НАДО заменять и обфусцировать имена классов и идентификаторов.
Префиксами я отделяю свои от сторонних, и мне не надо городить большие регулярки, причём отдельно для HTML, отдельно для JS/CSS.
В итоге, мне удобней открывать несколько окон, да и переключиться можно быстро.
А вообще, стараюсь не держать много открытых вкладок.
По личному опыту, проходит 2-3-4-7 дней, а они всё висят и висят.
В итоге их просто закрываешь, даже не читая, что там.
Как правило, открыл вкладку, прочитал, закрыл.
Пункт 4 «барахлит».
Сейчас решил попробовать случайные кнопки (поэксперементировать), чтобы выделить текст ссылки в Firefox.
Как-то быстро прошёл эксперимент.
Если зажать ALT и выделять текст, то текст будет выделяться, а не перетаскиваться.
И чего я раньше не пытался это проверить — столько лет мучений…
В старой Opera мне нравилось то, что некоторые «хакерские» JS события/действия и CSS хаки не работали.
В частности, onunload, или oncontextmenu, или user-select:none;
Конечно, иногда это было и минусом, но банальный пункт «Разрешить на этом сайте все события» решил бы проблему.
Сейчас какая-то странная тенденция…
Вместо работы над «полезностью» пытаются внести изменения в дизайн (расположение вкладок, кнопок и т.п.).
В последнем Firefox'е вообще из меню пропал пункт «Загрузки».
При взгляде на примеры не понятно, что значит item — это «товар как модель каталога» или же «товар как модель корзины».
Я твёрдо считаю, что язык программирования отличается от разговорного языка.
Поэтому в нём должны быть более сухие и максимально чёткие обозначения.
Пусть они читаются не так лаконично, зато исключается всякая двусмысленность.
>> говорили на одном языке с руководством и исполнителями
Для таких разговоров, зачастую, упускаются незначительные детали, чтобы не перегружать слушателей не столь важными данными.
Например, вывод каталога с учётом остатков или отображение разных цен для разных типов клиентов.
Да и, если уж так, то более понятней для руководителя будет читать:
— Пользователь -> Корзина -> Товар -> Название
— Каталог -> Товар -> Цена
А как цена определяется, как высчитывается — это тема для отдельного разговора с отдельным описанием логики.
>> описание вашей модели данных будет не универсальным и понятным лишь узкому кругу специалистов — программистам Yii
А в чём заключается неуниверсальность?
Есть модель пользователя, есть модель корзины.
Какая бы ни была платформа для разработки, надо организовать эту связь.
То есть, в любом случае будет связь (relation), а каким образом (на уровне framework'а) она будет организована — это не имеет значения к наименованию связи.
К тому же, префиксы и постфиксы не взяты наобум.
Они, в принципе, нормально вписываются в общие правила именования.
Взять ту же модель — по аналогии с UserForm / UserValidator / UserController есть также класс UserModel.
>> которых вы посвятили в свои правила
Этот вопрос уже поднимался.
Как я думал, и как подчеркнули в комментариях — есть стандарты, которых придерживаются программисты.
И чтобы программист понимал, что и как именуется, его надо будет обучить (предоставить регламент или справку).
Пока я вижу некоторую проблему только в этом.
habrastorage.org/files/5b5/dcd/b5e/5b5dcdb5ea6a42b39625d7e935c92478.jpg
И в топике указал это мнение.
Только иногда проще подсунуть под нос регламент и сказать, что надо писать префиксы, нежели научить программиста писать правильный код с phpdoc'ами и нормальными конструкциями.
Это хорошо, когда программист понимает всю логику сервиса/программы/сайта и пишет так, что не надо никаких комментариев.
Но ведь это, скажем так, редкость.
Как мне кажется, в некоторых случаях проще составить один документ на 1-2 листа с регламентом именования сущностей, чем 10-20 листов, где будут перечислены все примеры, как надо писать код, а как не надо.
Я написал статью, в которой рассказал о том, какие способы я использую для наименования сущностей в ЯП.
Вы же своим комментарием ничего толкового не сказали.
Прочитал я ваш комментарий, увидел, что вы придерживаетесь другой точки зрения.
А какой?
Где «именно конструктивного обсуждения такого подхода», о чём я просил в конце топика?
Я нисколько не обиделся, скорее, удивился, что комментаторы то и дело говорят, что это плохо, а почему — сказать явно не могут.
Лишь бы что-то написать…
Да, так и есть — вношу изменения вручную.
Честно, мне не сложно дописать пару-тройку строк (атрибут в phdoc, валидацию и relation).
Не всегда требуется указывать проверку или relation, поэтому вообще одна строка.
К слову, может быть у вас такого не было, но сгенерированная через gii модель опасна.
Дело в том, что gii не понимает, какие атрибуты надо разрешить редактировать, а какие нет.
И большинство так и оставляют валидацию критически важных полей типа id, parent_id, user_id и т.п.
А затем присваивают через $_POST['ModelName'].
Думаю, если вы знаете Yii, сможете понять, где уязвимость.
2.
Это не слово паразит — это префикс.
Тут более уместней сочетания «Модель пользователя», «Модель заказа», «Внешняя связь с заказом», «Внешная связь с документом».
И это, как мне кажется, более понятней, чем пытаться объяснить собеседнику, что не «пользователь, который на сайте» или «не документ word, а документ, но к заказу, а не к доставке».
3.
Тут в большей степени дело в том, что Yii использует метод, названный model.
Если же метод был бы назван по-другому, было бы даже более понятней.
К слову, мне кажется, что NewsModel со статичными переменными/константами/методами выглядит более понятней, чем просто News.
Я прочитал ваш первый комментарий, постарался узнать, почему вы так думаете.
Вы написали второй комментарий, из которого я тоже ничего полезного не вынес.
Не могу понять — зачем это писать?
Что значит — мешать в кучу?
У вас есть класс/идентификатор стиля — и вам его надо задействовать и в CSS, и в JS, и в PHP…
>> У каждого своя область использования и следовательно разные подходы к разработке.
>> То что прокатит в html в js может выйти боком.
Опять же, к чему это?
Это и так понятно.
2.
>> «умник» решивший что неплохо бы иметь перменную cl_container
Для этого есть регламент.
Хотя, на моей памяти ещё ни разу не встречалось таких переменных.
3.
Я не пытаюсь разработать стандарт для наименования.
Изначальная цель была — не придумать что-то, а спросить у сообщества, как они выходят из таких ситуаций.
Как они разделяют разные типы данных и именуют переменные.
Для себя я придумал такие вот префиксы и постфиксы.
И ожидал услышать адекватные «за» и «против».
Причём такие, чтобы я смог уверенно сказать «да, тут я не прав».
Пока я не увидел таких комментариев, хотя некоторые, замечу, дали повод задуматься.
Да и, наиболее используемых не так много.
Что касается «всё стараются завязывать на классах»…
Чем преимущество завязывания кнопки корзины на классы перед идентификатором?
Или ещё какой-нибудь блок, который уникален для сайта.
Например… блок сверху информацией о пользователе.
Я считаю, что идентификатор даёт другому программисту/дизайнеру понять, что этот элемент — единственный на сайте.
Он уникальный, и других таких нет.
А класс… он не уникальный, их много, разных, и одно и то же имя класса может использоваться для разных элементов.
Собственно, для этого изначально и предназначались идентификаторы и классы.
Стараюсь максимально покрывать ими код, в том числе и внутри методов, например, когда используется switch case.
А насчёт разных объектов…
Собственно, это я и имел ввиду, когда писал, что ссылка на класс через объединение строк — это плохо.
Только, не могу понять логики минусующих/плюсующих…
Почитайте насчёт того, что такое суффикс.
Вкратце:
— Префикс — то, что идёт прежде всего — перед ним ничего нет;
— Постфикс — то, что идёт после всех частей слова — за ним уже ничего нет;
— Суффикс — то что идёт после корня, за суффиксом может быть окончание.
>> И да, в PHP такое делать, несомненно, не стоит.
Почему?
Но суть не в том, что можно регулярку в поиск указать (это я знаю).
Суть в том, что одной регуляркой тут явно не обойдёшься.
Есть же ещё JavaScript и CSS, а также PHP файлы.
И там нельзя регуляркой найти — слишком много может быть частных случаев.
Навскидку:
— addClass('container')
— $('.container').remove()
— $container.append('OK')
— container = $(this)
В итоге, всё равно надо будет открывать и анализировать каждое совпадение слова «container».
Что касается cl_container.
Поиск через регулярки нужен, чтобы провести обфускацию и сжатие.
А в работе вообще не надо никаких регулярок — вбивай в поле поиска «cl_container» — и всё, что нашлось — всё классы CSS.
Я генерирую модель только один раз — изначально.
Затем уже вручную добавляю все связи и проверки.
По крайней мере мне не надо проверять, что изменилось, а что — нет.
Особенно это актуально, когда модель состоит не из 10-20 строчек по-умолчанию.
2.
Соглашусь, что префикс R и написание Rcomments — это бред, читаемость резко падает.
Но я же в топике написал не так, а R_, то есть R_Comments, R_CatalogCategory.
Неужели так сильно отличается читаемость R_Comments от comments?
3.
Про $newsModel->R_Author->name — тоже верно, читаемость не очень.
Но я ничего и не говорил про именование переменных — я писал про классы.
Более того, переменная — она локальная, и глупо добавлять постфикс Model.
Массивы я тоже не люблю — и об этом я тоже написал в своём топике.
Мне надо найти и заменить — статью кто-нибудь читает?
Вот есть класс container (приведённый в комментарии выше), и мне надо его заменить.
Я открываю форму поиска в IDE и ввожу туда слово «container».
Потом ставлю, что надо искать по файлам CSS / HTML / JS / PHP.
Вываливается 100-200 файлов.
По вашей логике, мне надо открыть все файлы и глазами пробежаться по всем совпадениям и заменить.
При этом, проанализировать, действительно ли это класс, а не что-то другое (например, не переменная JS).
Так?
В нашем обычном как бы и так все понятно:
Надо заменить его на что-то другое.
И как найти, где используется идентификатор «container»?
Все вьюшки, стили, JS-скрипты…
Не ясно почему легче.
Потому что есть разного рода расширения, плагины и т.п., где НЕ НАДО заменять и обфусцировать имена классов и идентификаторов.
Префиксами я отделяю свои от сторонних, и мне не надо городить большие регулярки, причём отдельно для HTML, отдельно для JS/CSS.
Причём, даже два раза — один раз в топике, другой раз — в комментарии.