Особенно, если ещё и смешать указатели, массивы и простые инстансы.
Но никогда я не вдавался особо в то, почему же так писать не рекомендуется. Ну очевидно мне это было. Однако сейчас работаю с коллегой который упрямо так и пищет (к счастью, указатели с массивами не так часто встречаются, что бы он и их смешивал. Но бывало... ), не смотря на мои, может быть, слабые аргументы.
Здравствуйте, Micker, Вы писали:
M>Может ли кто-то сказать веские аргументы за или против таких объявлений?
Аргумент один — coding style guide в вашей группе/компании.
Никаких реальных аргументов предпочесть одно другому нет, дело исключительно личного вкуса.
КР>Если твой коллега нарушает coding style то бороться следует
А если речь идет как раз о его создании и хочется что бы выбор того или иного стиля был максимльно аргументирован?
Жизнь, как игра —
идея паршивая,
графика обалденная...
Re[3]: Почему это "некрасивый" код?
От:
Аноним
Дата:
13.02.07 09:23
Оценка:
Здравствуйте, Micker, Вы писали:
КР>>Если твой коллега нарушает coding style то бороться следует M>А если речь идет как раз о его создании и хочется чтобы выбор того или иного стиля был максимльно аргументирован?
Ну так это ему следует аргументировать свою экзотику.
Здравствуйте, Micker, Вы писали:
M>Привет!
M>Всегда мне не нравились определения вида M>
M>double a = 6.0,
M> b = 0.0,
M> c = 0.5;
M>
M>Особенно, если ещё и смешать указатели, массивы и простые инстансы.
Могу приблизительно аргументировать почему мне не нравится:
1) Если тип переменной b потребуется заменить на float например, то это затронет следущие за этим переменные;
2) Зрительно мне лично приятно, когда тип переменной находится близко к имени;
3) Существуют языки, которые такую запись бы рассматривали как: для a тип определен, а b и c имеют динамический тип. Соответственно может внести путаницу;
4) Существуют языки (сходу щас не назову), где откомментировать что значит переменная a будет проблемой, например нельзя использовать однострочный комментарий //.
Здравствуйте, Micker, Вы писали:
M>Может ли кто-то сказать веские аргументы за или против таких объявлений?
чисто из привычек человеческих языков, где рекомендуется знаки препинания ставить после слова и пробелом потом, а не наоборот пристраивать к следующему слову
Здравствуйте, Micker, Вы писали:
КР>>Если твой коллега нарушает coding style то бороться следует M>А если речь идет как раз о его создании и хочется что бы выбор того или иного стиля был максимльно аргументирован?
Не знаю на сколько это серьезная аргументация, но в институте товарищ в цепочке таких определений нечаяно поставил ";" вместо "," — сработал неявный int (исходный тип был float) — все откомпилилось, а потом дООлго три человека искали сначала ошибку в алгоритме, потом долго думали почем 1/2 = 0, и только потом нашли злочастную ";"
С уважением, Владислав Полищук
Re[5]: Почему это "некрасивый" код?
От:
Аноним
Дата:
13.02.07 09:51
Оценка:
Здравствуйте, Аноним, Вы писали:
А>>Ну так это ему следует аргументировать свою экзотику.
А>а тут и аргументировать нечего, минимум кода всегда предпочтительнее, так как легче понимать.
Какой минимум? Как я понял, речь идет о том где ставить запятую — в начале строки или в конце.
Здравствуйте, Micker, Вы писали:
M>Может ли кто-то сказать веские аргументы за или против таких объявлений?
Аргумент "за" — Чтобы другому было трудно понять. У него самого с чтением чужого кода проблем не возникает, он привык. Это как левша-фехтовальщик, теннисист или боксер.
Здравствуйте, minorlogic, Вы писали:
M>>Может ли кто-то сказать веские аргументы за или против таких объявлений?
M>Так это же вам не нравится, может это вы нам поведаете ?
Я просил высказать как против так и за.
Спасибо тем, кто высказался по делу, особенно товарищу vladpol, который привел "случай из жизни". Лично мне хватило в свое время высказывания Страуструпа — "Язык программирования С++" — п 4.9.2 "Объявление нескольких имен" о плохой читаемости этого кода.
Я подозревал, что могут возникнуть проблемы описанные и vladpol и elmal (о том, что может понадобится поменять тип 1-й переменной, а замениь сразу всем), но к счастью еще не сталкивался с такими бедами.
Вы не считаете, что такие объявления череваты последствиями или не являются удобочитаемыми?
Жизнь, как игра —
идея паршивая,
графика обалденная...
Я вот лично согласен скорее с jazzer'ом, а ситуация, описанная vladpol — это крайний случай, нормальный компилятор С++/С такого попросту не допустит (причем это уж больше 10 лет так).
Of course, the code must be complete enough to compile and link.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Я вот лично согласен скорее с jazzer'ом, а ситуация, описанная vladpol — это крайний случай, нормальный компилятор С++/С такого попросту не допустит (причем это уж больше 10 лет так).
Удивительно, но я с ним тоже согласен. Вас наверное, как и "Какая разница" жалко моего коллегу (представляю какая картина предстоит вашим взглядам — затюканный перец, который ночами в хранилище перелоавчивает код, что бы объеденить объявления еще 3-х переменных)?
Но у нас нет пока полиси. Его предстоит создать. Хочется, что бы его требования были обоснованные, а не выясненные простым голосованием присутствующих.Для этого-то я спросил ваше мнение.
Очень легко жить, когда за тебя решили как жить хорошо (по написанному полиси). Сложнее понять — как же будет хорошо (написать полиси).
Жизнь, как игра —
идея паршивая,
графика обалденная...
M>Удивительно, но я с ним тоже согласен. Вас наверное, как и "Какая разница" жалко моего коллегу (представляю какая картина предстоит вашим взглядам — затюканный перец, который ночами в хранилище перелоавчивает код, что бы объеденить объявления еще 3-х переменных)?
Не, мне безразличен и твой коллега, и ты Причем одинаково.
Я видел много примеров офигенно кривого форматирования и приведенный тобою пример — это не страшно
Я имел и иногда имею дело с кодом, в котором зачастую вообще нет сколько-нибудь упорядоченного форматирования — пишут его ооочень неглупые люди, которые способны понимать вещи, недоступные мне (предметная область у них на порядки посложнее программирования), однако нормально писать они не могут — постоянные проблемы с отступами, мешанина из табов и пробелов — и т.п. Мне приставать к ним с такой фигней — стыдно. Раз им так удобно — пусть Лишь бы не падало и не текло
M>Но у нас нет пока полиси. Его предстоит создать. Хочется, что бы его требования были обоснованные, а не выясненные простым голосованием присутствующих.Для этого-то я спросил ваше мнение.
ИМХО — как раз никакой обоснованности тут и не может быть, а только результат голосования — все эти "удобно/неудобно читаемо/нечитаемо" — 100% субъективно. Это ж не то же самое, как обсуждать, использовать ли смарт_поинтеры или нет, использовать ли стандартный вектор или писать голимы new double[size] и т.п. — там реально объективные доводы.
M>Очень легко жить, когда за тебя решили как жить хорошо (по написанному полиси). Сложнее понять — как же будет хорошо (написать полиси).
Блин, это все философия уже какая-то Надо чтобы проги работали
Я, когда понадобилось, легко привык к определенному стилю форматирования и именования и никаких проблем у меня не было, а если пишу что-то для себя, например, я оформляю по-другому.
Of course, the code must be complete enough to compile and link.
M>Но у нас нет пока полиси. Его предстоит создать. Хочется, что бы его требования были обоснованные, а не выясненные простым голосованием присутствующих.Для этого-то я спросил ваше мнение.
Мое имхо — выносить в code style rules тему топика я не стал бы
Когда объем этих rules становится большой то эти правила стараются нарушить
Есть бодее важные правила которые стоит занести в code style
M>Экономит что ли...
M>Может ли кто-то сказать веские аргументы за или против таких объявлений?
Мне здесь не нравится на уровне кода три вещи:
запятые в начале строки;
одинокая точка с запятой;
неграмотный английский язык в именах переменных и файлов.
Первые два пункта я могу понять и простить: при таком оформлении кода удобно добавлять новые переменные в этот список, и остаётся возможность поменять тип сразу всем.
Третий пункт понять могу, но буду ругаться вслух (сам править код только из-за этого не буду).
И, наконец, если в таком объявлении будут вместе объявлены значения, ссылки и указатели, то, вероятно, буду бить по рукам (разносить в отдельные объявления, если понадобится работать над таким исходником).
Если же отвлечься от кода и осмотреться на уровень выше, то таких фич, как непрерывное воспроизведение звука в процессе поиска или архивации в программе быть не должно.
Как пример того на что следует обращать внимание , это
1. Вместо идентификаторов для звуков используется жестко прописсаный набор строк, хардкодед.
2. Значит скорее всего нет разделения данные — код.
3. Значения могли бы задаваться константно в изолированном месте.
например можно так
class soundId
{
typedef id std::string;
static const id wavOnSearchStarted;
static const id wavViaSearching;
static const id wavOnTimeout;
static const id wavOnFound;
static const id wavOnArchieveStarted;
static const id wavViaArchieving;
static const id wavOnArchieved;
};
ну и т.п. Прошу пример не судить строго, это первое что пришло в голову.
Прошу прощения, промахнулся кнопкой
R>Для начала правильно задавайте вопросы,
Код должен работать и быть легким в сопровождении в первую очередь, что такое "некрасивый" лично я без понятия.
-Код может быть трудным для чтения и понимания. Тут вы врядли сомжете возразить — читается он на ура
-Некоторые приемы могут быть obfuscating. Да в некотором роде
float a,b;
float a;b; // конечно человеку это сложно заметить но любой пристойный компилятор выдаст варнинг - аргумент слабыйfloat *a,b; // можно возразить что указатель относиться к типу а не к экземпляру - ИМХО неплохой аргумент, ошибки тут маловероятны, ptr и value копилятор не перепутаетfloat **a,*b; // ага - вот это уже лучше - a++, b++ будут работать - весомое возражение если вы часто пользуетесь адресной арифметикой. Но в том то и дело что умные люди перешли на контейнеры.
для интереса я его прогнал через parasoft C++ test — он мне ничего путного не возразил.
Здравствуйте, Micker, Вы писали:
КР>>Если твой коллега нарушает coding style то бороться следует M>А если речь идет как раз о его создании и хочется что бы выбор того или иного стиля был максимльно аргументирован?
Знаешь, я тоже раньше хотел, что бы код других сотрудников в проекте по стилю напоминал мой, но затем прочел у Саттера в рекомендациях по стилю такой совет — "Не мелочитесь" в отношение того, как и что регламентировать в отношение стиля.
Здравствуйте, Fdooch, Вы писали:
F>Такой стиль объявления дает меньше измененных строчек в diff и source control программах.
ничего он не дает, это миф.
В смысле, он выигрывает при добавлении в конец, а при вставке в начало у тебя будут две измененных строчки.
Обратная (традиционная) запись дает обратный эффект: две строчки при добавлении в конец, одна при вставке в середину и в начало.
Поскольку в реальной жизни люди стараются добавлять не в конец, а к ближайшей по смыслу строчке, она с огромной вероятностью окажется в середине (а вот если люди всегда добавляют только в конец, а не по смыслу, то тут как раз с большой вероятностью ты получишь конфликт при одновременном коммите).
например, в енумах с автоматической нумерацией вариантов я всегда вставляю в конце пункт типа last (для проверки корректности конверсии из целого в енум и просто для итерации по значениям енума) — так у тебя, куда не добавляй, при традиционной записи с запятой в конце всегда будет только одна добавленная строчка.
Ну очевидно мне это было. Однако сейчас работаю с коллегой который упрямо так и пищет (к счастью, указатели с массивами не так часто встречаются, что бы он и их смешивал. Но бывало... ), не смотря на мои, может быть, слабые аргументы.
