Здравствуйте, smeeld, Вы писали:
S>И вызов __Unwind_RaiseException произойдёт при всяком throw, ибо как есть стандарт.
Речь как бы не совсем про это была.
Здравствуйте, GhostCoders, Вы писали:
GC>Вообще непробиваемый. С ним можно спорить и час и два и весь день. Толку почти 0. GC>Упрямый. Систему контроля версий (у нас GIT), не любит. Его перл это "это гит виноват".
вина лида очевидна. Не позднее 4го дня затихшего сотрудника надо заставить систематизировать то, что он делает. "2 месяца" это фейспалм.
Как там было "Поросеночек рос, рос и выросло ... Что выросло, то выросло!". Тем более когда человек нуждается в помощи по наведению порядка.
В нынешнем виде этот код обуза для проекта и тянет его ко дну. Включать в билд можно только если экономика требует. Иначе в папочку "музей".
Здравствуйте, landerhigh, Вы писали:
L>Заголовок с копирайтом позволяет сразу понять, что это, откуда оно взялось и кто в этом виноват. Даже когда работаешь из движущегося поезда без подключения к системе.
Работал однажды над легаси проектом. Там такое было принято. Причём когда файл кто-то редактировал, то про коммите изменений в шапку дописывалось примерно следующее:
<номер изменения> <автор> <сообщение> <дата>
Ну и что оно помогает понять? Особенно когда количество изменений переваливает за сотню (так и было), а кода который люди добавляли в файле уже и не осталось. Без системы контроля версий это просто нагромождение бессмысленной "информации".
К счастью, в какой-то момент от этого решили избавиться.
L>Я знаю. Это не отменяет того, что хорошей инженерной практикой является комментирование подобного. Даже если это всем известно, это не перестает быть грязным хаком.
Не уверен. А то так можно далеко зайти. Скажем, "pragma once" стандартом так и не стала. Тем не менее, (практически) все используют и сомневаюсь, что комментируют. А что? Тоже своего рода "нестандартный хак".
Здравствуйте, vpchelko, Вы писали:
V>Да и нотации типа m_, в новом коде я не приемлю, уже есть нормальные IDE.
m_ пишут не вместо подсветки, а чтобы не писать this-> если есть параметр или локальная переменная с тем же именем.
struct Foo {
int x;
void f(int x) {
this->x = x;
}
void g() {
...
int x = ...
...
this->x = x;
}
};
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Kernan, Вы писали:
K>>Речь как бы не совсем про это была.
S>Короче, вместо try{ throw }catch() используем старый добрый do{ break; while(0) S>так правильней.
Нет, правильнее выделить сущности и использовать RAII, try-catch там вообще может быть не нужен. Если бы там были только математические вычисления то подход с do-break имел бы смысл.
Здравствуйте, GhostCoders, Вы писали:
GC>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.
О, да! Руку мастера сразу видно ! Особенно тернарный оператор нравится (что? switch? enum? ну не надо усложнять такой компактный код!): GC>
DE>Работал однажды над легаси проектом. Там такое было принято. Причём когда файл кто-то редактировал, то про коммите изменений в шапку дописывалось примерно следующее: DE><номер изменения> <автор> <сообщение> <дата>
У нас тоже такое было. Это отросло из старых проектов, когда VCS либо не было, либо были в зачаточном состоянии.
DE>Ну и что оно помогает понять? Особенно когда количество изменений переваливает за сотню (так и было), а кода который люди добавляли в файле уже и не осталось. Без системы контроля версий это просто нагромождение бессмысленной "информации".
Шапка помогает отследить происхождение файла. Кто, когда, какой проект. Сразу понятно, есть ли смысл искать аффтара.
Нередко бывает, кто какой-то файл копируется из проекта в проект, во внтутренние тулзы, откуда он опять попадает в продакшен и т.п.
DE>К счастью, в какой-то момент от этого решили избавиться.
Наши тоже прекратили ручное отслеживание истории при переходе на VCS.
L>>Я знаю. Это не отменяет того, что хорошей инженерной практикой является комментирование подобного. Даже если это всем известно, это не перестает быть грязным хаком. DE>Не уверен. А то так можно далеко зайти. Скажем, "pragma once" стандартом так и не стала. Тем не менее, (практически) все используют и сомневаюсь, что комментируют. А что? Тоже своего рода "нестандартный хак".
Вещи вроде
#pragma once
обычно относят в coding conventions, где описывается, используются ли guard macro или эта прагма.
Здравствуйте, landerhigh, Вы писали:
L>У нас тоже такое было. Это отросло из старых проектов, когда VCS либо не было, либо были в зачаточном состоянии.
лично мне недостает (ибо на текущем месте никто не использует) той шапки, где VCS автоматом прописывает дату коммита, автора и ревизию (как тут: https://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_16.html ). все же помогало ориентироваться в проекте и выявлять случаи, когда "ой, забыл твой фикс затащить" или "кто эту тут пошевелил код, вчера было по-другому": по шапке можно быстро понять неактуальность файла. внешние тулзы все же более неповоротливы. минусом только было сложность анализа диффа файлов для одного проекта в разных бранчах сторонними утилитами типа Araxis — дифф показывался для всех файлов из-за разницы в шапке.
Здравствуйте, GhostCoders, Вы писали:
GC>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.
Обычно именно сишники выдают такой С++ код. Или драйверисты.
В общем случае не лечится. Их период воспитывания вкуса пришелся на другую эпоху, для них подобный код действительно неплох. Можно дать им книжку типа Фаулера ("Рефакторинг") и надеятся, что привьются правильные подходы. Но не факт...
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Abyx, Вы писали:
A>m_ пишут не вместо подсветки, а чтобы не писать this-> если есть параметр или локальная переменная с тем же именем. A>
A>struct Foo {
A> int x;
A> void f(int x) {
this->>x = x;
A> }
A> void g() {
A> ...
A> int x = ...
A> ...
this->>x = x;
A> }
A>};
A>
Я в таких случаях за использование this->x = x;
К тому же я еще пишу много на java — там такой стиль обще принят. Например автогенерация кода для getter/setter и конструкторов инициализирующих поля объекта.
Мне например очень удобно, когда код смотрится одинаково на C++ и на Java — да и других языках. Да и в принципе мне все равно какой язык использовать. Но эталон кодинг стайла — пока что Java.
код едва вытягивает на оценку "удовлетворительно", но шанс у этого кода есть — его исправить можно.
недостатки обсосали выше, но особенно "порадовало" использование тернарных операторов вкупе с плохим форматированием — такой код читать тяжко.
огромные методы, которые не понятно что делают, и которые можно читать с перекурами вызывают желание основательно отрефакторить этот код.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, omgOnoz, Вы писали:
A>>m_ пишут не вместо подсветки, а чтобы не писать this-> если есть параметр или локальная переменная с тем же именем. A>>
A>> void f(int x) {
A>> this->x = x;
A>> }
A>>
O>Я в таких случаях за использование this->x = x;
и если ты забудешь написать this-> то получишь трудно отлавливаемый баг.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>>мало коментариев.
MTD>В хорошем коде комментариев быть не должно.
Не согласен,
например мы реализовали какой-то сложный математический
метод, нужен хотя бы комментарий, типа метод такой-то, см. статью такую-то,
а лучше бы еще объяснение почему выбран именно метод (хотя это можно и в документацию
засунуть).
Иными словами как бы хорош код не был, всегда существуют такие алгоритмы,
которые сложно понять имея только код.
A>>потери истории изменений и т.п. случаются, но такое бывает ну очень редко.
L>Достаточно одного раза в 10 лет, и каждый раз придется заново проводить расследование "откуда вообще мы это взяли".
Здравствуйте, Zhendos, Вы писали:
A>>>потери истории изменений и т.п. случаются, но такое бывает ну очень редко.
L>>Достаточно одного раза в 10 лет, и каждый раз придется заново проводить расследование "откуда вообще мы это взяли".
Z>Бэкапы делать пробовали?
А подумать, что означает "потеря истории изменений", как она происходит и как и когда обнаруживается, и каким боком тут бекапы, подумать не пробовали, прежде чем написать?
Здравствуйте, Zhendos, Вы писали:
Z>например мы реализовали какой-то сложный математический Z>метод, нужен хотя бы комментарий, типа метод такой-то, см. статью такую-то,
Это единственный случай когда в хорошем коде комментарий уместен.
Здравствуйте, MTD, Вы писали:
Z>>например мы реализовали какой-то сложный математический Z>>метод, нужен хотя бы комментарий, типа метод такой-то, см. статью такую-то,
MTD>Это единственный случай когда в хорошем коде комментарий уместен.
Не, далеко не единственный. Есть куча ситуаций, где недостаточно внимательный разработчик может нарваться на неприятности. Я, например, всегда комментирую "проваливающиеся" (без break) ветки в switch, или места, где важен порядок объявления членов класса. Со сторонними библиотеками тоже всяких приколов хватает. Вообще, нарвался на неожиданность — прокомментируй. Не понял чего-то быстро (засомневался, а все ли тут делается корректно и вынужден перепроверять, к примеру) в своем же коде через год после написания — прокомментируй, по свежим впечатлениям.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
