Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, k.o., Вы писали:


Z_>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?

KO>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Z_>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA? Мой мозг отказывается такое воспринимать принципиально, это уже признак говнокода — дальше смотреть можно, но нужно ли? Я еще понимаю по работе, когда за это деньги платят, и то повбывав бы, но за просто так себя насиловать? С трудом вынудил себя найти ту же архитектурно заложенную опасность целочисленного переполнения, но целиком анализировать всю идею кода, а тем более просчитывать все возможные ошибки... "На фиг, на фиг — к терапевту" (с) При таком похабном написании в коде еще и ни одного коммента, которые призваны как-то сглаживать проблемы понимания когда ничего больше не помогает. Препод-стайл — "я написал, я такой умный, а вы втыкайте в мои скрижали". Надо иметь какое-то уважение к читателям если хочешь нормальной реакции.
согласен бессмысленые названия можно юзать только в циклах i, j, ii, jj, x, y или для указателей p, q (и тут же их использовать) все остальное надо нормально обозначать

Здравствуйте, jyuyjiyuijyu, Вы писали:


Z_>>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?

KO>>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Z_>>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA? Мой мозг отказывается такое воспринимать принципиально, это уже признак говнокода — дальше смотреть можно, но нужно ли? Я еще понимаю по работе, когда за это деньги платят, и то повбывав бы, но за просто так себя насиловать? С трудом вынудил себя найти ту же архитектурно заложенную опасность целочисленного переполнения, но целиком анализировать всю идею кода, а тем более просчитывать все возможные ошибки... "На фиг, на фиг — к терапевту" (с) При таком похабном написании в коде еще и ни одного коммента, которые призваны как-то сглаживать проблемы понимания когда ничего больше не помогает. Препод-стайл — "я написал, я такой умный, а вы втыкайте в мои скрижали". Надо иметь какое-то уважение к читателям если хочешь нормальной реакции.
J>согласен бессмысленые названия можно юзать только в циклах i, j, ii, jj, x, y или для указателей p, q (и тут же их использовать) все остальное надо нормально обозначать
ну в общем да. только я бы еще добавил, что для указателя можно использовать специальную переменную, типа my_pointer, а для итераторов, если их много и особенно если циклы вложены друг в друга, то тоже давать осмысленные имена — employee_iterator, manager_iterator.

Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, k.o., Вы писали:


Z_>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?

KO>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Z_>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA?

Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.

Здравствуйте, GhostCoders, Вы писали:
GC>Здраствуйте!
GC>Оцените плиз следующий лисапед.
GC>Как положительные так и отрицательные качества.
GC>Планирется Class1Impl сделать ...

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

Здравствуйте, shasa, Вы писали:

S>Не тому нынче учат в университетах. Учат городить велосипед, вместо того чтобы решать конкретные задачи.
Я не согласен, уметь решать задачи по рецепту — "Павлова", нажали кнопку получили профит — можно обучить даже... собаку.

Тут нужен баланс.

Здравствуйте, k.o., Вы писали:


Z_>>>>Это действительно мелочи, в сравнении с тем, что, как говорят китайцы, "а нахуа" вообще этот код?

KO>>>Да ладно, обыкновенный pimpl, что тут непонятного-то? Есть, конечно, проблемы такие как изобретение велосипеда и нарушение SRP, но с кодом вполне можно работать. При необходимости он легко рефакторится до удобоваримого состояния. А вот отлавливать баги вызванные такой реализацией оператора присваивания бывает совсем не весело. В зависимости от везения, проявления могут быть разной степени фееричности. Во всяком случае, эта проблема на порядки отличается от гипотетически возможного переполнения счётчика ссылок.
Z_>>Лично у меня на второй строчке этого кода забывается что написано на первой. Еще отцы-основателиКерниган с Ритчи на первых же страницах говорили, что переменным и функциям нужно давать как можно более осмысленные имена. Не, ну не как у гугла в его глюгловом движке V8 — название функции в 42 буквы, а 2-3 слова, передающие основную суть, некоторые слова можно даже сократить. Че блин за переменная mA?

KO>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.
Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод. Ну если всех устраивает — то пожалуйста, фапайте, я просто не в кугсе.

Здравствуйте, dZentle_man, Вы писали:

KO>>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.
Z_>Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод.
Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции

Дабы закрыть эту тему, пока она не переросла в более абстрактную и холиварную, этот пост.

В примерах, традиционно, сущностям, не имеющим отношения к делу, даются более абстрактные имена: foo, bar, func, Class, SomeClass, data или чуть более конкретные, демонстрирующие смысловую нагрузку:

// Класс с типом type, являющимся ссылкой:
struct SomeClassWithReferenceType {
    typedef int& type;
};

// Просто какой-то класс, без ссылок:
struct SomeClass {
    typedef int type;
};

// И дальше описание какого-нибудь шаблонного трюка на этой основе с уже осмысленными именами.
// ...

Или пример здесь

Автор: remark
Дата: 02.03.10

— имя, не имеющее отношения к примеру — foo; здесь

Автор: jazzer
Дата: 02.03.10

— вообще f. Это не говнокод (в рабочем коде, конечно, критерии другие и там "foo/bar" смотрятся дико), это естественное разделение важных сущностей от неважных, т.к. всё остальное названо осмысленно.

Z_>Ну если всех устраивает — то пожалуйста, фапайте, я просто не в кугсе.
А никто и не фапает.

Здравствуйте, Alexey F, Вы писали:


KO>>>Ну, возможно, я ошибаюсь, но я подумал, что это просто пример, потому и названия смысла не имеют. Косвенно это подтверждается тем, что все имена имеющие отношения к сути вопроса, выглядят более понятно: AddRef/Release/mRefCount/mInternalImpl. Да и вообще, это обычное дело на форумах.
Z_>>Как ваш пример читать, если названия переменных смысла не имеют? Значит на форумах обычно постят говнокод.
AF>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции
Очень осмысленное название.

AF>Дабы закрыть эту тему, пока она не переросла в более абстрактную и холиварную, этот пост.

AF>В примерах, традиционно, сущностям, не имеющим отношения к делу, даются более абстрактные имена: foo, bar, func, Class, SomeClass, data или чуть более конкретные, демонстрирующие смысловую нагрузку:
Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.

AF>Или пример здесь

Автор: remark
Дата: 02.03.10

— имя, не имеющее отношения к примеру — foo
А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода.

Здравствуйте, dZentle_man, Вы писали:

Z_>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.

Ну что можно сказать? А то, что Вы не читали Страуструпа.

Сейчас открыл книжку Страуструпа "Язык программирования С++".
Листаю от начала,

первый пример кода более-менее, но третий такой:

   #include "stack.h"  // используем интерфейс стека

   static char v [ stack_size ]; // "static" означает локальный 
                          // в данном файле\модуле

    static char * p = v; // стек внчала пуст

    void push( char c)
    {
       ....

кусочек из пятого примера

void f()
{

шестой пример

class complex
{
   double re, im;

седьмой

void f()
{
   complex a = 2.3;
   complex b = 1 / a;
   complex c = a + b * complex( 1, 2.3 );

чуть далее:

class shape
{
...
    kind k;

то есть почти каждый третий (или даже второй) пример содержит однобуквенные идентификаторы.

Открыл книгу Мейерса, "Наиболее эффективный С++".
Та же самая картина. Используются "f", "X", "x".

Открываем Саттера. Аналогичная картина.

Второе. Вызывает улыбку Ваша фраза "архитектурно заложенную ошибку переполнения счетчика..." и Ваши нечеловеческие усилия по обнаружению онной.
Вы не отличаете "архитектуру" от реализации.


Как то у меня был в стадии тестирования один молодой амбициозный человек. Претендовал на роль разработчика приложений на С++.
Говорил, что он мол бы работать менеджером проектов, так как прочитал много книг про управления проектами.
Много критиковал существующий код, писал в комментариях к существующему коду "THIS CODE IS VERY VERY VERY BAD" и т.д.

С ним у меня работать не получилось, я отказался от работы с ним.

Через пару лет, я связался с ним опять, и попросил его написать примеры использования одной библиотеки,
программы ва стиле "Hello, World!", так как все мы были заняты и отвлекаться на это времени не было.
Но он ответил, что не занимается уже С++, и целиком перешел на PHP и HTML, так как его уровень не достаточен для серьезной работы на С++.

Стиль Ваших реплик показывает, что Вы недалеко ушли от такого молодого человека.

Либо другое, то что Ваш уровень С++ может и не такой низкий, но Вы — типичный тролль. У вас самое главное оскорбить, унизить кого-то или что-то. Возможно, из-за комплекса неполноценности или каким-то другим причинам. А может из-за банального занудства.

Мне пришлось потратить около получаса своего высокооплачиваемого времени на написание ответа Вам.
НЕ КОРМИТЕ ТРОЛЯ! Больше ответа Вам я не напишу, не надейтесь!

Здравствуйте, dZentle_man, Вы писали:

AF>>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции
Z_>Очень осмысленное название.
Z_>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.

"Data" — некая абстрактная полезная нагрузка, заглушка для примера. Намёк, что в рабочем коде здесь будут реальные данные с осмысленным именем.
А "понабирали" ( ) мы это с форумов, книг и собственных экспериментов, когда имя не важно, а важен тип или само присутствие сущности в коде (см. ссылки на сообщения, которые я привёл в прошлом посте). Уж что-что, а книги изобилуют такими именами . Беру Майерса, листаю — сходу нахожу абстратные Handle, a, b, c, d, e, n, d (последние два — вместо полных numerator, denumerator), f1, f2, temp1, temp2... А там, где автор хочет показать более конкретные примеры — Person, PersonInfo, DatabaseID. В соседнем сообщении у Страуструпа нашли много подобного (нет под рукой книги).
Ибо зачем нагружать читателя лишними подробностями? Абстракция.

Вот если

template<class T>
struct AddReference { typedef T& type; };

обзовут FooBar — доставай линейку бить по рукам (с другой стороны, если этот же AddReference наравне с другими выступает в роли некоторого функтора (не важно какого) — FooBar будет вполне к месту).

AF>>Или пример здесь

Автор: remark
Дата: 02.03.10

— имя, не имеющее отношения к примеру — foo
Z_>А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода.
Да легко. Однобуквенное имя, не параметр шаблона + остальные функции включают в себя "A" как часть имени, оперируя с ним — значит, это некая полезная нагрузка.
Можно было назвать "A" "image", сделать ему соответствующий class Image и продемонстрировать работу на примере подсчёта ссылок на изображения. Но самым лучшим было бы написать в самом начале, для чего это нужно, чтобы мы не разбирались — с "A" оно работает, с картинками или ещё с чем Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.

Здравствуйте, GhostCoders, Вы писали:


Z_>>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.

GC>Ну что можно сказать? А то, что Вы не читали Страуструпа.

GC>Сейчас открыл книжку Страуструпа "Язык программирования С++".
GC>Листаю от начала,
Бгг) Сколько неправды, наговора, неверных предпосылок и умозаключений в одном посте) От начала говорите листаете? Да кого вообще это начало интересует, до 5 главы, про классы? Читаем "предварительные замечания", первый же раздел — "структура книги":
В главах 2, 3 и 4 описываются средства С++, которые не используются для определения новых типов:
основные типы, выражения и структуры управления. Другими словами, эти главы содержат описание
той части языка, которая по сути представляет С.
Первая же глава — это краткое описание языка, хотя по содержанию это еще и из-рук-вон-описание, не обладающей ни краеугольной полнотой изложения, ни систематичностью, способствующей первично вникнуть в суть языка — только свалка надерганных кусков и фраз. Да, не самая удачная глава книги, и вообще страуструп пишет довольно заумно, но тем не менее — вы бы знали об этом, если бы сами потрудились его прочитать)


GC>первый пример кода более-менее, но третий такой:
GC>

GC>   #include "stack.h"  // используем интерфейс стека

GC>   static char v [ stack_size ]; // "static" означает локальный 
GC>                          // в данном файле\модуле

GC>    static char * p = v; // стек внчала пуст

GC>    void push( char c)
GC>    {
GC>       ....
GC>

Опять же, вы сравните — десять строчек у него, и 50 у вас. Причем у него логика сосредоточена в этих 10 строчках, а у вас она прокинута между всеми 50. То, что вы не видите разницы — говорит лишь о том, что вы вообще плохо себе представляете как пишется читаемый код, и почему один код читаемее другого.

GC>кусочек из пятого примера

GC>

GC>void f()
GC>{
GC>

К функции f() в этом коде нет ни одного обращения — это просто объявление функции, его вообще могло бы и не быть, и код не утратил бы наглядности.

GC>шестой пример

GC>

GC>class complex
GC>{
GC>   double re, im;
GC>

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


GC>то есть почти каждый третий (или даже второй) пример содержит однобуквенные идентификаторы.
Если бы у вас в коде каждая вторая переменная была бы читаемой — код был бы в два раза понятнее.


GC>Открыл книгу Мейерса, "Наиболее эффективный С++".
GC>Та же самая картина. Используются "f", "X", "x".
GC>Открываем Саттера. Аналогичная картина.
Идем в подворотню — там пасаны колются — делаем то же самое. Че, пример маргинальный? Идем в голливуд — там кокаин нюхают — делаем то же самое.


GC>Второе. Вызывает улыбку Ваша фраза "архитектурно заложенную ошибку переполнения счетчика..." и Ваши нечеловеческие усилия по обнаружению онной.
GC>Вы не отличаете "архитектуру" от реализации.
А вот это уже голословное утверждение) Вы архитектурно выбрали целочисленный тип для хранения данных счетчика, так и реализовали. Или вы начинаете думать какую же переменную взять на стадии реализации, когда уже пишите код?


GC>Как то у меня был в стадии тестирования один молодой амбициозный человек. Претендовал на роль разработчика приложений на С++.
GC>Говорил, что он мол бы работать менеджером проектов, так как прочитал много книг про управления проектами.
GC>Много критиковал существующий код, писал в комментариях к существующему коду "THIS CODE IS VERY VERY VERY BAD" и т.д.
Я вам конкретно сказал чем плох ваш код, а не вери-вери бэд. Хотя вы даже в этом не видите отличия)


GC>С ним у меня работать не получилось, я отказался от работы с ним.
Я бы тоже отказался от работы с человеком, чьи комментарии в коде сводятся к "THIS CODE IS VERY VERY VERY BAD".


GC>Через пару лет, я связался с ним опять, и попросил его написать примеры использования одной библиотеки,
GC>программы ва стиле "Hello, World!", так как все мы были заняты и отвлекаться на это времени не было.
GC>Но он ответил, что не занимается уже С++, и целиком перешел на PHP и HTML, так как его уровень не достаточен для серьезной работы на С++.
То есть ваш код, в котором не происходит валидации данных для страховки от переполнения, пригоден для серьезной работы?


GC>Стиль Ваших реплик показывает, что Вы недалеко ушли от такого молодого человека.
Скорее уж ваших)


GC>Либо другое, то что Ваш уровень С++ может и не такой низкий, но Вы — типичный тролль. У вас самое главное оскорбить, унизить кого-то или что-то. Возможно, из-за комплекса неполноценности или каким-то другим причинам. А может из-за банального занудства.
Сколько возможных объяснений одного, вами же высказанного предположения) Я вам конкретно сказал чем код плох, и остановился на этом. Вас же прорвало. На мой взгляд это может говорить о том, что вы не привыкли, не умеете и не считает нужным писать читаемый код, да еще и плохо воспринимаете конструктивную критику. А между тем критики и просили.


GC>Мне пришлось потратить около получаса своего высокооплачиваемого времени на написание ответа Вам.
Вам еще и деньги за такой код платят? Это где так, интересно?


GC>НЕ КОРМИТЕ ТРОЛЯ! Больше ответа Вам я не напишу, не надейтесь!
Ах, я теперь уже стопудовый тролль, уже точно не ламер в плюсах? Будь я модератором — банил бы тех, кто поминает слово "тролль", потому что поминают его те, кто на самом деле не знают что такое троллинг.

Здравствуйте, Alexey F, Вы писали:


AF>>>Топикстартеру нужно было бы назвать "mA" как "mData", тогда бы это не вызвало такой реакции
Z_>>Очень осмысленное название.
Z_>>Че то страуструп в примерах работает с классами employee и manager, а не с какими-то абстрактными названиями. Не знаю откуда вы всего этого понабрали, но я считаю, что код, в котором хотя бы часть переменных/функций не имеет осмысленных имен — только теряет в читаемости.
AF>"Data" — некая абстрактная полезная нагрузка, заглушка для примера. Намёк, что в рабочем коде здесь будут реальные данные с осмысленным именем.
Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data?


AF>А "понабирали" ( ) мы это с форумов, книг и собственных экспериментов, когда имя не важно, а важен тип или само присутствие сущности в коде (см. ссылки на сообщения, которые я привёл в прошлом посте).
Я пока что таких кодов не видел, где это не важно.


AF>Уж что-что, а книги изобилуют такими именами . Беру Майерса, листаю — сходу нахожу абстратные Handle, a, b, c, d, e, n, d (последние два — вместо полных numerator, denumerator), f1, f2, temp1, temp2...
Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа. Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода. А ТС вывалил 50 строк.


AF>>>Или пример здесь

Автор: remark
Дата: 02.03.10

— имя, не имеющее отношения к примеру — foo
Z_>>А с чего вы взяли что счетчик mA не имеет отношения к делу? Мне, например, это совсем не очевидно при беглом взгляде на код. А читать вдумчиво уже неудобно, из-за нечитаемости кода.
AF>Да легко. Однобуквенное имя, не параметр шаблона + остальные функции включают в себя "A" как часть имени, оперируя с ним — значит, это некая полезная нагрузка.
Вообще-то, если говорить о стандартных обозначениях, то A — используется как знак работы с ANSI-строками, что меня, например, вводит в заблуждение когда я смотрю на функцию SetParamAImpl(int a).


AF>Можно было назвать "A" "image", сделать ему соответствующий class Image и продемонстрировать работу на примере подсчёта ссылок на изображения. Но самым лучшим было бы написать в самом начале, для чего это нужно, чтобы мы не разбирались — с "A" оно работает, с картинками или ещё с чем
Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue).


AF>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают.

Здравствуйте, dZentle_man, Вы писали:

Z_>Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять)
Z_>

Z_>    int mRefCount;
Z_>    virtual void AddRef()
Z_>    { 
Z_>        mRefCount++; 
Z_>    }
Z_>

Здравствуйте, dZentle_man, Вы писали:
Есть такое заболевание называется "псевдоинтелектуальность"
Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе.

Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, GhostCoders, Вы писали:

GC>>Здраствуйте!

GC>>Оцените плиз следующий лисапед.
Z_>"Что это было, Пух?" (с)
Z_>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто.

Здравствуйте, dZentle_man, Вы писали:

[Цитаты не по порядку]

Z_>Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data?
А он там не исполняет роль ObjectCounter'а, но это не важно, т.к.:

Z_>Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue).
Вот и нашли довольно абстрактное имя, тем не менее передающее суть предмета .
Собственно, за подобные имена в примерах я выступаю — когда они к месту, конечно. Разве что на "Data" меня заклинило и я ушёл в offtop относительно изначального поста.

Z_>Вообще-то, если говорить о стандартных обозначениях, то A — используется как знак работы с ANSI-строками, что меня, например, вводит в заблуждение когда я смотрю на функцию SetParamAImpl(int a).
Если бы в коде было WinAPI, я бы тоже об это споткнулся. А так мы уже выяснили, что название было неудачным.

Z_>Я пока что таких кодов не видел, где это не важно.
Да много примеров, связанные с демонстрацией потрохов языка. Таких как я приводил по ссылкам или, особенно, в началах книг по какому-либо языку, когда объясняют синтаксис и основы. Допустим, автор хочет показать следующий синтаксис:

if( void* ptr = f() ) { // и не стал придумывать ничего сложнее ptr и f, хотя и мог
    // ...
}

А вот если этот кусок будет не сам по себе, а внутри сложной ф-ции, выполняющей осмысленные действия — это будет отвратительно .

Z_>Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа.
Даже спорить не о чем. Не только Керниган с Ритчи, но и каждый второй автор расписывает преимущества осмысленных имён. И это правильно — чем быстрее новичок уйдёт от "кулхацкерских" __XxX______, _$$$abc, a, b, x, xx — тем лучше.

Z_>Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода.
Важное дополнение — примеры с такими именами должны быть маленькими и "сами по себе"

Z_>А ТС вывалил 50 строк.
Z_>Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают.
ИМХО, даже с именем parameter для примера в 50 строк на C++ надо было дать сопроводительные комментарии вида "зачем это всё нужно". Ибо 50 строк — не 5-10, и код для форума: даже с внятными именами надо сидеть, разбираться и угадывать, что на самом деле хотел автор. Впрочем, повторяюсь:
AF>>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.

Здравствуйте, IROV.., Вы писали:

IRO>Здравствуйте, dZentle_man, Вы писали:

Z_>>Если уж дотрахиваться до таких мелочей, то надо и на переполнение проверять)
Z_>>

Z_>>    int mRefCount;
Z_>>    virtual void AddRef()
Z_>>    { 
Z_>>        mRefCount++; 
Z_>>    }
Z_>>

IRO>Здравствуйте, dZentle_man, Вы писали:
IRO>Есть такое заболевание называется "псевдоинтелектуальность"
Вообще то болезнями обычно интересуются когда у самих здоровье подорвано...


IRO>Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе.
А кто сказал что мы запускаем код на 32-битной системе? А если мы сделаем правку когда счетчик сможет посчитать так, что его переполнит? Вы еще скажите, что это нормально — оставить переменную без валидации если в обозримом будущем ничто не угрожает переполнением? Валидация данных — это краеугольный камень построения безглючных и безопасных приложений. Проверяются все данные, без исключения. Мы не всегда может просчитать все возможные варианты и последствия, но всегда можем предусмотреть проверку. Но, я опять же, сказал, что в данном случае — это дотрахиваться до мелочей, то есть я не считаю это самой большой проблемой этого кода.

Здравствуйте, IROV.., Вы писали:


GC>>>Здраствуйте!

GC>>>Оцените плиз следующий лисапед.
Z_>>"Что это было, Пух?" (с)
Z_>>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
IRO>А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто.
С _такими_ велосипедами и правда — и голова будет болеть, и пузо будет урчать.

Здравствуйте, dZentle_man, Вы писали:

IRO>>Покажи пример, когда ты сможешь переполнить рефкаунтер представленый 32 битным целым числом в 32 битной системе.
Z_>А кто сказал что мы запускаем код на 32-битной системе?
На других 64-битных системах будем использовать 64 битные целые числа.
А на других, другое.. и это норма.

Z_>А если мы сделаем правку когда счетчик сможет посчитать так, что его переполнит? Вы еще скажите, что это нормально — оставить Z_>переменную без валидации если в обозримом будущем ничто не угрожает переполнением? Валидация данных — это краеугольный камень Z_>построения безглючных и безопасных приложений. Проверяются все данные, без исключения. Мы не всегда может просчитать все возможные Z_>варианты и последствия, но всегда можем предусмотреть проверку. Но, я опять же, сказал, что в данном случае — это дотрахиваться до Z_>мелочей, то есть я не считаю это самой большой проблемой этого кода.
Я не вижу тут ответа на вопрос, троллизм в чистом виде. А если, а представте, а что если прилетит НЛО! А вдруг ктото пропишет по памяти. И куча других нелепых ситуаций не касающихся вопросу, прошу не писать.
Покажи ситуацию когда ты сможешь переполнить рефкаунтер.

Здравствуйте, dZentle_man, Вы писали:

Z_>Здравствуйте, IROV.., Вы писали:


GC>>>>Здраствуйте!

GC>>>>Оцените плиз следующий лисапед.
Z_>>>"Что это было, Пух?" (с)
Z_>>>Завидую людям, у которых столько свободного времени, что они могут заниматься всякими глупостями, у которых нет ни практической цели, ни вообще какой-либо цели, кроме как "поиспражняться в кодинге".
IRO>>А я завидую людям которые умеют вызывать функции у библиотеки и получать за это деньги. Голова не болит, и пузо сыто.
Z_>С _такими_ велосипедами и правда — и голова будет болеть, и пузо будет урчать.
а что в __этом__ велосипеде такого страшного??
Интересно было посмотреть на __твои__ кошерные велосипеды тогда, и щас. Хотя я думаю можно и щас.

Интересно у тебя есть своя мало мальски интересная — зделаная тобой библиотека, контейнер, и еще чтото, на что можно вглянуть.

Здравствуйте, Alexey F, Вы писали:


Z_>>Почему не обозвать как ObjectCounter? Почему я должен думать зачем нужна ваша Data?
AF>А он там не исполняет роль ObjectCounter'а, но это не важно, т.к.:
Вот именно, что не понятно зачем он нужен. А из нечитаемого кода это понятнее не становится.

Z_>>Зачем придумывать применение, когда можно сделать абстрактное название, которое передаст суть объекта, и подойдет в любом случае — с чем бы мы ни работали — с изображениями, музыкой или текстами? Например Parameter? Тогда даже название функции SetParamAImpl(int a) упростилось бы до SetParamImpl(int ParameterValue).
AF>Вот и нашли довольно абстрактное имя, тем не менее передающее суть предмета .
Ну Parameter хотя бы может быть и свойством предмета, а Data — это уже скорее какие-то данные, которые еще не понятно зачем могут быть нужны.


Z_>>Я пока что таких кодов не видел, где это не важно.
AF>Да много примеров, связанные с демонстрацией потрохов языка. Таких как я приводил по ссылкам или, особенно, в началах книг по какому-либо языку, когда объясняют синтаксис и основы. Допустим, автор хочет показать следующий синтаксис:
AF>

AF>if( void* ptr = f() ) { // и не стал придумывать ничего сложнее ptr и f, хотя и мог
AF>    // ...
AF>}
AF>

AF>А вот если этот кусок будет не сам по себе, а внутри сложной ф-ции, выполняющей осмысленные действия — это будет отвратительно .


Z_>>Это пример плохого программирования. Вы классический труд Кернигана с Ритчи открывали? Они там на первых же страницах рекомендуют давать переменным осмысленные имена. Да, идея не очень очевидная для начинающего, но они правильно говорят, потому что уже собаку на кодинге съели. Ну да, применение перменных типа a, b, c встречается у всех, в том числе и у Кернигана с Ритчи, и у страуструпа.
AF>Даже спорить не о чем. Не только Керниган с Ритчи, но и каждый второй автор расписывает преимущества осмысленных имён.
Вот именно, но эти два — это просто классика, как можно считать себя знающим язык не открывая труда его создателей?


AF>И это правильно — чем быстрее новичок уйдёт от "кулхацкерских" __XxX______, _$$$abc, a, b, x, xx — тем лучше.
Именно.


Z_>>Но, во-первых, обычно пример в книге — это 5-10 строчек кода, а во-вторых, читаемость это не всегда улучшает даже в таких небольших кусочках кода.
AF>Важное дополнение — примеры с такими именами должны быть маленькими и "сами по себе"
Именно.

Z_>>А ТС вывалил 50 строк.
Z_>>Если давать адекватные названия, то не нужно никаких описаний и, тем более, выдуманных прикладных областей. А вот если наоборот, то даже описания и подробные комменты не так уж сильно помогают.
AF>ИМХО, даже с именем parameter для примера в 50 строк на C++ надо было дать сопроводительные комментарии вида "зачем это всё нужно".
Да, они желаетельны. Вообще не понятно на что можно рассчитывать вываливая нечитаемый код без комментов. Но наверное там где хорошо оплачивают время это в порядке вещей.


AF>>>Ибо 50 строк — не 5-10, и код для форума: даже с внятными именами надо сидеть, разбираться и угадывать, что на самом деле хотел автор. Впрочем, повторяюсь:
AF>>>Серьёзно, маленькое описание в начале ввело бы нас в курс дела без необходимости топикстартеру выдумывать прикладную область вокруг примера.
С одной стороны да. С другой — насколько внятным было бы это описание? Стал бы автор объяснять действительно нужные моменты, или он набросал бы пару абзацев булшита чтобы поставить галочку "описание — есть"? Впрочем меня эта тема не так уж интересует, я сказал свое мнение один раз — код нечитаемый, а остальное — уже в ответ на объснение мне что я не прав.