Вот такое подозрение возникло у меня при чтении книжки «Чистый код» 2016 года выпуска.
Сначала всё было более-менее ничего. Разумные пожелания. Когда-то я подходил к этой книжке в магазине и открыл страницу, где советовали делать функции короче. С тех пор мои функции стали намного короче.
Но когда я купил книжку, стал её читать не спеша и дошёл до главы о функциях, там стали советовать делать функции желательно вовсе без параметров, с одним допустимо, с двумя - плохо, с тремя - вообще ужас.
Параметры предлагалось группировать в объекты или запихивать в переменные класса!
Для начала, я бы посмотрел, как автор этой книги предложил бы переработать ls или grep. Это ведь тоже процедуры в контексте операционной системы, неважно, что они вызываются обычно из bash.
Количество параметров у них порядка десятков.
Идея запихнуть всё в класс и сделать жирное «состояние» мне вообще не понравилась. Эта идея однозначно делает код более неявным, менее ясным и даже менее надёжным. Напротив, сейчас считается более модным применять чистое ФП везде, где это только возможно. А тут предлагается совершенно противоположная идея: увеличивать степень императивности.
Тут-то я и заподозрил неладное. Если сделать короткие функции по 4-5 строк с длинными говорящими именами, избавиться от локальных переменных (которые наверняка не сохраняются в метаданных), то вся структура кода будет находиться в метаданных, причём смысл каждого малюсенького куска кода будет выражен на понятном человеку языке (ведь нужно тщательно выбирать понятные имена). Каждая сущность данных также будет поименована. А уж связь между ними легко достаётся из байт-кода. Учитывая, что байт-код Java сам по себе легко декомпилируется, подобная практика сделает реверс инжиниринг совершенно тривиальным.
Туда же идут и сообщения о комментариях. Конечно, всё автор пишет правильно - комментарии не проверяются компилятором, устаревают и т.п.. Однако, нападки на комментарий, проясняющий смысл регэкспа, выглядят совсем уж неестественными и автор не смог предложить конкретного способа, как избавиться от такого комментария без потери полезной информации. Вместо этого автор просто повторил свою рекомендацию дважды. Это выглядело как журналистский приём, когда неубедительность аргумента компенсируется многократностью его повторения.
Старательно выражая содержимое комментариев в именовании кода, автор кода любезно предоставляет реверс-инженеру нужную ему информацию в уже готовом виде - в противном случае он бы её не смог добыть.
