Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType. Для этого поиском смотрим где он используется в коде. Если мы используем явное указание типа, то нет проблем. Но если мы используем auto то мы не найдем места где используется SomeType.
Если объем кодовой базы большой, то это будет проблема. Или нет?
МР>// here
МР>auto var1 = ...;
МР>// there
МР>SomeType var2 = ...;
МР>
МР>Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType. Для этого поиском смотрим где он используется в коде. Если мы используем явное указание типа, то нет проблем. Но если мы используем auto то мы не найдем места где используется SomeType.
МР>Если объем кодовой базы большой, то это будет проблема. Или нет?
Не проблема, если рефакторить не поиском, а рефакторилкой/искалкой, оно разберется.
Также не проблема, если (1) это auto var1 = new SomeType()
МР>// here
МР>auto var1 = ...;
МР>// there
МР>SomeType var2 = ...;
МР>
МР>Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType. Для этого поиском смотрим где он используется в коде. Если мы используем явное указание типа, то нет проблем. Но если мы используем auto то мы не найдем места где используется SomeType. МР>Если объем кодовой базы большой, то это будет проблема. Или нет?
Лично я, вопреки широко распространенным рекомендациям, пока еще не созрел для того, чтобы применять auto везде-везде, где только можно. Признаться, у меня нет даже какого-то строгого правила, когда использовать auto, а когда проставить тип явно. В каждом отдельном случае я принимаю отдельное решение, руководствуясь... хрен знает, чем руководствуясь. Ну вот в данном конкретном случае я бы оставил SomeType, не стал бы заменять его на auto.
МР>Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType.
Там справа должно быть какое-то выражение, которое возвращает SomeType. Либо это что-то вроде вызова конструктора, и такие места всё равно найдутся, либо какая-то функция, возвращающая SomeType.
Если мы SomeType меняем/убираем, то меняется семантика функции, так что всё равно надо искать все её вхождения.
В конце концов, код
auto x = f1(x, y, z);
f2( x );
не сильно отличается от
f2( f1(x, y, z) );
При этом по второй версии вопросов про рефакторинг, как я понимаю, не возникает.
С другой стороны у auto, есть коннотация, интересная с точки зрения рефакторинга. Одна из стратегий использования auto -- писать auto в клиентском коде, в том случае, если в клиентском коде не важен тип переменной. А если важен, но из выражения не очевиден, то указывать его точно. Это позволяет при рефакторинге быстро отличить те места, где автор думал, что тип важен от тех, где думал, что не важен...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет!
МР>
МР>// here
МР>auto var1 = ...;
МР>// there
МР>SomeType var2 = ...;
МР>
по-моему auto как раз призван помогать в рефакторинге. Если вы меняете тип SomeType на SomeOtherType (а этот случай куда более частый, чем тотальное удаление), то первый вариант уже не нуждается в рефакторинге (он уже такой как надо), тогда как второй надо найти и исправить.
Здравствуйте, Erop, Вы писали:
E>В конце концов, код E>
auto x = f1(x, y, z);
E>f2( x );
не сильно отличается от
f2( f1(x, y, z) );
E>При этом по второй версии вопросов про рефакторинг, как я понимаю, не возникает.
Да, кстати. Я уже на автомате минимизирую количество локальных переменных в коде. Там, где должна возникнуть локальная переменная, я, с большой вероятностью, сделаю декомпозицию функций и эта переменная превратится в формальный параметр. Но с другой стороны, типы формальных параметров всегда заданы явно и легко находятся поиском, если, конечно, оставить за скобками лямбды и шаблонные функции.
Здравствуйте, rg45, Вы писали:
R>Лично я, вопреки широко распространенным рекомендациям, пока еще не созрел для того, чтобы применять auto везде-везде, где только можно. Признаться, у меня нет даже какого-то строгого правила, когда использовать auto, а когда проставить тип явно. В каждом отдельном случае я принимаю отдельное решение, руководствуясь... хрен знает, чем руководствуясь. Ну вот в данном конкретном случае я бы оставил SomeType, не стал бы заменять его на auto.
У меня сформировалась привычка ставить auto в трёх случаях:
1. Итераторы: не std::map<std::string, std::string>::iterator, а просто auto.
2. Лямбды тоже с auto, это вообще логично и удобно.
3. Промежуточные вычисления в больших многоэтажных формулах. Можно записать в одну строку или нельзя, но я часто выделяю кусочки формул (типа числителя или знаменателя), обратные значения и т.п. в отдельные локальные переменные для читаемости. Там ставлю auto, чтобы меньше было возни с типами.
Здравствуйте, Erop, Вы писали:
E>В конце концов, код E>
auto x = f1(x, y, z);
E>f2( x );
не сильно отличается от
f2( f1(x, y, z) );
E>При этом по второй версии вопросов про рефакторинг, как я понимаю, не возникает.
Ну как не сильно отличается...
Как минимум, мы меняем время жизни всех участников формулы (продлеваем промежуточному значению и укорачиваем аргументам).
И ещё и можем разные сигнатуры f2 вызвать (если там const T& против T&&).
Здравствуйте, Кодт, Вы писали:
E>>В конце концов, код E>>
auto x = f1(x, y, z);
E>>f2( x );
не сильно отличается от
f2( f1(x, y, z) );
E>>При этом по второй версии вопросов про рефакторинг, как я понимаю, не возникает.
К>Ну как не сильно отличается... К>Как минимум, мы меняем время жизни всех участников формулы (продлеваем промежуточному значению и укорачиваем аргументам). К>И ещё и можем разные сигнатуры f2 вызвать (если там const T& против T&&).
Ну это всё понятно, и всякие там auto& тоже бывают, но, с т. з, рефакторинга, IMHO, это примерно одно и тоже. Ну, то есть, если надо переписывать или инспектировать один вариант, то и второй надо, и наоборот.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
МР>Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType. Для этого поиском смотрим где он используется в коде. Если мы используем явное указание типа, то нет проблем. Но если мы используем auto то мы не найдем места где используется SomeType.
Если убрать SomeType, то места, где он используется просто не соберутся.
Еще можно не убирать его совсем, а сделать [deprecated]] и пересобрать проект с нуля. Тогда все места, где он используется подсветятся.
Здравствуйте, bnk, Вы писали:
bnk>Не проблема, если рефакторить не поиском, а рефакторилкой/искалкой, оно разберется.
А можно поподробнее? В Visual Studio как искать?
bnk>Также не проблема, если (1) это auto var1 = new SomeType()
Ну это да.
Здравствуйте, Erop, Вы писали:
E>В конце концов, код E>
auto x = f1(x, y, z);
E>f2( x );
не сильно отличается от
f2( f1(x, y, z) );
E>При этом по второй версии вопросов про рефакторинг, как я понимаю, не возникает.
Почему не сильно?
f2(SomeType); // Поиском сразу найду эту функцию и исправлю.
Не только в связи с рефакторингом вопрос про auto возникает — допустим я хочу узнать где и как в коде используется SomeType. Если по всюду используются auto, то трудно будет найти все места где используется SomeType и соответственно выяснить для чего он используется.
auto добавили чтобы в шаблонах типы руками не выводить, т.к. компилятору будет виднее
использовать auto в обычном коде это просто апогей лени кодописаря и насилование мозга для того кто будет занимаеться поддержкой кода
Здравствуйте, Максим Рогожин, Вы писали:
bnk>>Не проблема, если рефакторить не поиском, а рефакторилкой/искалкой, оно разберется. МР>А можно поподробнее? В Visual Studio как искать?
Я имел в виду просто правая кнопка -> "Find All References".
Здравствуйте, Nuzhny, Вы писали:
N>1. Итераторы: не std::map<std::string, std::string>::iterator, а просто auto.
1.1 при слишком частых повторах таких сочетаний типов, я использую using
using Map2S = std::map<std::string, std::string>
using Map2V = std::vector<Map2S>;
using Map2SCI = Map2S::const_iterator;
И так далее. В случае замены основного типа (не вдаваясь в философию созданий архитектур) весь код автоматически под него перестраивается.
Единственное, у меня нет чёткого понимания, как правильно делать нотацию. Поэтому пока получается спонтанно. Был бы рад, если кто-то поделился мыслями по поводу использования using вообще и нотаций в частности.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Допустим нужно сделать рефакторинг и например убрать (или изменить) тип SomeType. Для этого поиском смотрим где он используется в коде. Если мы используем явное указание типа, то нет проблем. Но если мы используем auto то мы не найдем места где используется SomeType.
Ты найдёшь функцию, которая возвращает SomeType или которая выводит SomeType как свой возврат из своих параметров.
МР>f2(SomeType); // Поиском сразу найду эту функцию и исправлю.
МР>
Так в обеих версиях кода найдёшь...
МР>Не только в связи с рефакторингом вопрос про auto возникает — допустим я хочу узнать где и как в коде используется SomeType. Если по всюду используются auto, то трудно будет найти все места где используется SomeType и соответственно выяснить для чего он используется.
Это очень сильно зависит от того, что ты понимаешь под "использоваться".
То, что тип возвращается из какой-то функции или в какую-то передаётся, ты найдёшь.
А если код получает что-то из функции получить_итерируемую_коллекцию, и отдать в функцию, обработать_итерируемую_коллекцию, то считаешь ли ты, что в этом коде используется именно этот тип?
А ещё ведь бывают шаблоны. Скажем обработать_итерируемую_коллекцию вполне может быть шаблонной...
Так что тут, наоборот, auto позволяет показать в коде, где важно какой тип у переменной, а где важно, что это результат какого-то конкретного выражения, а тип не важен...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском