Человек, не знающий языка, не поймёт что ты тут написал.
Человек, знающий язык, поймёт, что ты написал лютый бред, да ещё и крайне плохо.
Получили абсолютно неюзабельный самописный недо-рефлекшн, делающий нормальную разработку невозможной, требующий постоянной поддержки штанов руками (пойди да оберни каждое поле), ну и заодно люто раздувающий любой код как по памяти, так и по времени выполнения.
Я б прошел мимо ничего не сказав, но к сожалению есть риск, что кто-то посередине прочитает статью и подумает, что всё написанное в ней — хорошая идея. А это непрямым образом создаёт проблемы конкретно мне. И так внятных джуниоров сложно найти, так ещё и из каждого надо потом выбивать подобную ересь, которую он где-то в интернетах прочитал.
Дружище, если ты хочешь написать хорошую статью по программированию:
1. Определись для кого пишешь. Либо для людей, не знающих про конструкторы, либо для людей, которым зачем-то понадобился твой недо-рефлекшн. Это две разные группы людей.
2. Определись, какую задачу решаешь. Потрать время на объяснение цели, а не оправдание своего письменного стиля:
(да-да, тавтология-повторение)
3. Сконцентрируйся на сути, а не на мусоре. Все поняли уже, что ты не в курсе, как в 2020м году правильно передавать строчки в конструктор, а заодно не понимаешь, что std::string тут изначально не нужен, ну так и не трать время на это. Воткни один любой вариант, напиши "добавьте тут чего хотите", и не копипасть два варианта конструктора пять раз подряд.
4. Самое важное: попроси ревью у коллег. Со всеми бывают задвиги, когда вроде написал что-то, а потом смотришь через два дня и стыдно. В этом нет ничего страшного. Для того и нужно работать в команде, чтоб такая фигня не попадала в продакшн, ну или в твоём случае в статью.
Если вы хотите дать совет, не стоит начинать комментарий с фразы "эталон бесполезной статьи". но я Вам подыграю. Эталон бесполезного комментария. "Человек, знающий язык, поймёт, что ты написал лютый бред, да ещё и крайне плохо." - тоже весьма конструктивно. Данное решение успешно работает и работало на двух проектах, находящихся в продакшне, и оно себя отлично зарекомендовало. Более того, я заметил недостаток отсутствия этого подхода на проекте, работающем по такому же принципу, но без автоматического построения иерархии. Макрос для объявления поля - не такая уж и большая плата, и иерархия защищена от неправильного построения. "Я б прошел мимо ничего не сказав, но к сожалению есть риск, что кто-то посередине прочитает статью и подумает, что всё написанное в ней — хорошая идея." - в статье был описан определённый класс задач и архитектур, для которых это хорошая идея. "так ещё и из каждого надо потом выбивать подобную ересь, которую он где-то в интернетах прочитал." - это конкретно ваша проблема, не стоит всем её вываливать.
Самое печальное - это рейтинг статьи. Вроде никто не поддерживает автора в комментариях, но много людей наставили ей плюсы. Хотя по-хорошему, это как раз та статься, на которой должна сработать автомодерация.
Просто эталон бесполезной статьи.
Человек, не знающий языка, не поймёт что ты тут написал.
Человек, знающий язык, поймёт, что ты написал лютый бред, да ещё и крайне плохо.
Получили абсолютно неюзабельный самописный недо-рефлекшн, делающий нормальную разработку невозможной, требующий постоянной поддержки штанов руками (пойди да оберни каждое поле), ну и заодно люто раздувающий любой код как по памяти, так и по времени выполнения.
Я б прошел мимо ничего не сказав, но к сожалению есть риск, что кто-то посередине прочитает статью и подумает, что всё написанное в ней — хорошая идея. А это непрямым образом создаёт проблемы конкретно мне. И так внятных джуниоров сложно найти, так ещё и из каждого надо потом выбивать подобную ересь, которую он где-то в интернетах прочитал.
Дружище, если ты хочешь написать хорошую статью по программированию:
1. Определись для кого пишешь. Либо для людей, не знающих про конструкторы, либо для людей, которым зачем-то понадобился твой недо-рефлекшн. Это две разные группы людей.
2. Определись, какую задачу решаешь. Потрать время на объяснение цели, а не оправдание своего письменного стиля:
(да-да, тавтология-повторение)
3. Сконцентрируйся на сути, а не на мусоре. Все поняли уже, что ты не в курсе, как в 2020м году правильно передавать строчки в конструктор, а заодно не понимаешь, что std::string тут изначально не нужен, ну так и не трать время на это. Воткни один любой вариант, напиши "добавьте тут чего хотите", и не копипасть два варианта конструктора пять раз подряд.
4. Самое важное: попроси ревью у коллег. Со всеми бывают задвиги, когда вроде написал что-то, а потом смотришь через два дня и стыдно. В этом нет ничего страшного. Для того и нужно работать в команде, чтоб такая фигня не попадала в продакшн, ну или в твоём случае в статью.
Если вы хотите дать совет, не стоит начинать комментарий с фразы "эталон бесполезной статьи". но я Вам подыграю.
Эталон бесполезного комментария.
"Человек, знающий язык, поймёт, что ты написал лютый бред, да ещё и крайне плохо." - тоже весьма конструктивно. Данное решение успешно работает и работало на двух проектах, находящихся в продакшне, и оно себя отлично зарекомендовало. Более того, я заметил недостаток отсутствия этого подхода на проекте, работающем по такому же принципу, но без автоматического построения иерархии.
Макрос для объявления поля - не такая уж и большая плата, и иерархия защищена от неправильного построения.
"Я б прошел мимо ничего не сказав, но к сожалению есть риск, что кто-то посередине прочитает статью и подумает, что всё написанное в ней — хорошая идея." - в статье был описан определённый класс задач и архитектур, для которых это хорошая идея.
"так ещё и из каждого надо потом выбивать подобную ересь, которую он где-то в интернетах прочитал." - это конкретно ваша проблема, не стоит всем её вываливать.
Самое печальное - это рейтинг статьи. Вроде никто не поддерживает автора в комментариях, но много людей наставили ей плюсы. Хотя по-хорошему, это как раз та статься, на которой должна сработать автомодерация.