Авторазработка

Заставь программиста код писать, он себе в ногу выстрелит

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

Сегодня я хотел бы поговорить про новые возможности и тенденции развития современных языков программирования... Нет, конечно, на такую статью у меня пока не хватит терпения. Я просто хотел бы рассказать о некотором опыте работы с такой простой вещью, как использование к качестве типа переменной ключевого слова auto, доступного ещё начиная с С++11.

По поводу читабельности и поддерживаемости кода сломано уже немало копий. Пожалуй, добавлю и я свои пять копеек по данному вопросу.

Вообще я ничего не имею против нового функционала и развития ЯП в целом и С++ в частности. Да, я ярый противник внедрения в реальные проекты кода по принципу "потому что я знаю крутую фичу языка" вместо "потому что это сильно повышает читаемость". Новые фичи, безусловно, нужны и важны, и их знание и изучение - это часть работы любого хорошего программиста, но я за то, чтобы использовать их там, где это действительно уместно.

Собственно, против auto я тоже имею не так уж и много. Я прекрасно могу понять, когда мы делаем auto для переменной с семантикой итерации по контейнеру - это на самом деле удобно, и я это всячески поддерживаю. Я могу понять, когда мы делаем auto в роли typedef, то бишь вместо длиннющей декларации на пол-строки: действительно, некоторые типы (особенно шаблонные) лучше вообще не произносить даже мысленно, чтобы случайно не призвать Ктулху. Я вообще многое могу понять, но вот двух вещей я не могу понять в принципе:


1. Какой профит от auto в случае встроенных типов? Их реально настолько дольше писать, что стОит жертвовать самодокументированностью переменных? Я понимаю посыл "выбирайте для переменных правильные имена, и всё будет ОК", но неужели чуть-чуть дополнительной инфы о переменной (особенно являющейся возвращаемым значением из функции/метода) правда не стОит пары букв? Вот типичный кейс:

auto probability = get_probability(....);

Серьёзно? Это действительно сильно экономит время по сравнению с

double probability = get_probability();

?

Возможно, сторонники duck typing закидают меня камнями, но я не боюсь. Мне неважно, что для кого-то тип этой переменной кажется лишним: ничего не мешает его игнорить. А в случае auto гордое игнорирование информации уже не поможет: придётся либо смотреть сигнатуру метода, либо смотреть кейсы использования этой переменной. И мне совершенно несложно написать на пару букв больше, чтобы хоть немного облегчить жизнь того, кому это поддерживать.

2. Какой профит от auto в случае переменных пользовательского типа? Там вообще автокомплит почти у всех работает, у нас в компании в значительной степени из-за этого требование на CamelCase для типов, чтобы можно было первые две буквы набрать и ктрл+пробел. Вы мне можете цитировать Саттера сколько угодно, но вы сами-то верите, что

TinyKitten ball_of_furr = something();

является менее удобным, чем


auto tiny_kitten_little_ball_of_furr = something();

или, уж тем более, чем


auto little_ball_of_furr = something();
(как, кстати, большая часть народа и напишет)?


Вы правда в это верите? Саттер крутой мужик, да, у него память терабайтами измеряется, а скорость соображалки терафлопами. И что, у всех так? У меня вот что-то не совсем, а время на чтение кода хочется минимизировать.


Вот что мне делать с переменной, выползшей из метода? Сигнатуру метода смотреть? Я посмотрю, конечно. И запомню на какое-то время. А через неделю опять сигнатуру смотреть, потому что у меня есть много вещей, которые мне помнить важнее, а то, что можно сделать с переменными в каждой конкретной точке кода, я бы предпочёл видеть прямо в коде, а не догадываться. Я понимаю, что есть автокомплит, но он вот правда у всех всегда работает по сложным вложенным структурам данных, упакованных в набор контейнеров? При этом даже не тормозит? Кажется, я очень завидую мощности вашего компьютера. Вы там не ватсона, случаев, юзаете в качестве рабочей станции?

Дальше будет ещё немного примеров, в которых упомянуты шорткаты. Практически все программисты их очень любят, а если кто-то говорит, что не любит, то он обычно либо всё равно пользуется, либо лукавит, либо не программист. Речь идёт про Qt Creator, в clion другие шорткаты, в VS совсем другие, но суть от этого не меняется. А остальные IDE, КМК, до них не дотягивают.


Представим: переменная в скоупе хотя бы 50 строк насыщенного кода. Скоуп больше - ситуация ещё ярче. Переменная некого пользовательского типа. Как посмотреть, какие у неё доступны поля/методы? Автокомплит? Отлично, пишем её имя (то самое длинное, понятное, прекрасное, в лучших традициях жанра, хорошо описывающее её сущность имя), или кликаем на существующее в подходящем месте, ктрл+вправо, точка, ждём... Профит. Не утомляет? Поздравляю, у вас прекрасное терпение. Что ещё? А, локатор. Ктрл + К, М пробел .... Как там этот тип-то назывался.... Чешем репу... Смотрим в аутлайн.... Ага, ок. Вспомнили, ентер, профит. Хм, а зачем вообще локатор-то, и так аутлайн открыли на нужном месте, чтобы вспомнить. Ах да, clion впереди планеты всей, и уже почти научился переходить к объявлению. Объявлению чего? Переменной? Вот незадача, мы интерфейс хотели. Научился переходить к интерфейсу? Серьёзно? И правда работает? Даже с полиморфными типами? И не тормозит? Ох, я, кажется, опять немного завидую. Вы точно не Cray CS-Storm упёрли себе для работы? Ладно, ладно. У вас просто памяти в системе очень много и С++-парсер в среде идеальный, такое очень часто встречается у сферических IDE в вакууме.

А теперь как задача в 98% случаев решится в qtcreator/clion, когда у нас не auto-переменная: F2-F2-профит: весь хедер (а в случае библиотеки он ещё и с доксиджен-комментами) как на ладони. *ДВА* раза клацнуть по клавиатуре. Меньше полусекунды. И аутлайн его бонусом слева. альт-влево - альт-влево - вернулись к месту, где были (ещё секунда). Остальное время - на чтение/написание кода... И это не говоря уже о том, что если вы помните примерный набор и иерархию классов в проекте, то код получается читать раза в 3 быстрее, чем с auto на каждом углу. Мне кажется, оно стОит того, чтобы пренебречь вот именно в этом конкретном случае заветами дядюшки Саттера. Я бы сказал "но решать всё равно вам", но не скажу, потому что не хочу оказаться в роли человека, которому доведётся поддерживать такой код. Лучше я выражу надежду, что мой пост кому-то немного упростит суровые трудовые будни.


Оставьте комментарий

You must be logged in to post a comment.