Про живое и мёртвое

[vit_r]

ivan_gandhi пишет в своём блоге вот такое

ResourceRepositoryManager rrm = new ResourceRepositoryManagerImpl(resourceRepository, databaseManagementFuckingShit, remoteAccessRemoteControl, remoteAccessLocalControl, localAccessRemoteControl, localAccessLocalControl, userId, customerId, itemIdContainerImpl)

После чего ужасно страдает по поводу непонятности, мутности и некрасивости, воспевая хвалу функциональщине. Хотя и ребёнку понятно, что серебряные пули не лучше свинцовых, просто одна сложность заменяется другой.

Да, так учат писать Гугл и Микрософт (у них дофига бабла), так учат писать авторы умных книжек, код которых можно использовать, если к нему прикреплено две введения и три страницы разбора, так пишут гуру новейших языков, чтобы удивить и поразить начинающих адептов, так повторяют за ними миллионы леммингов, которым главное скормить код компилятору, чтоб потом ухватиться за очередную «сложную задачу»

Дюжину лет назад я начал писать «The Dragon of The Source Code». Кое-кто даже видел черновик. Потом я забросил, потому как это оказалось никому не нужно. Людям нужна магия. И, желательно, с очень дорогим тулом.

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

Та же строчка в промышленной разработке выглядит вот так

ResourceRepositoryManager rrm 
  = new ResourceRepositoryManagerImpl(  
                                                // 
           resource_repository                  //
         , database_management_fucking_shit     //FIXME: does not work 4 test
                                                //       if customerId == 0 

                                                //== Remote
         , remote_access_remote_control         // 
         , remote_access_local_control          //

                                                //== Local
         , local_access_remote_control          // 
         , local_access_local_control           //       4 test or 4 production

                                                //== IDs
         , user_ID                              // 
         , customer_ID                          //     ! may be 0

                                                // WTF?
         , item_ID_Container_Impl               //     !? optional
         ) ; 

Я не буду тут объяснять, почему. Что-то просто для красоты, вроде //== У чего-то есть важные причины. Та же запятая в начале не просто маркирует колонку, продолжает блок и останавливает взгляд, но и позволяет с наименьшей болезненностью произвести манипуляции вроде

         //TEST  , item_ID_Container_Impl               //     !? optional

Какие процессы, какие lean и kanaban, какая инженерия и конвейер, если хитромудрейшие из программистов не в состоянии писать живой код.

Ладно, в последнее время чего-то слишком много про программизм. Сейчас будут картинки.

Comments

[gineer.livejournal.com]

А не было бы еще лучше,
если бы все эти вкусности и правильности поддерживались IDE?

[vit-r.livejournal.com]

IDE делают те программисты, которые пишут программы, которые пишут программы. Потому оно всё со звонками и колокольчиками, а профи работают в vim, или в Emacs.

В последнем можно форматирование под себя настроить и блоки схлопвыть, но практика показывает, удобнее, когда все свистелки и перделки просто отключены.

[vit-r.livejournal.com]

Во многомегобайтном проекте она штука программиста обычно работает с небольшим куском, интерфейсы к которому хорошо прописаны и ограниченны. Если там каша, то это проблема больше архитектуры, чем применяемых редакторов.

[sab123.livejournal.com]

Правильные языки не возражают против закрывающих запятых, типа

{
a,
b,
c,
}

[esc.livejournal.com]

Как зовут этих языков? Я бы в них пошёл. Меня страшно раздражают запятые в начале строки. Просто до нечитабельности.

[alll]

Конкретно та конструкция, которую привёл автор начавшего тред камента, допустима в том же C++. Да и в Java, емнип. Типа как-то так:
int I[] = { 1, 2, 3, };
Но он слегка передёргивает, топикстартер-то говорил о списке аргументов функции.

[vit-r.livejournal.com]

Разницы никакой нет. Так стоит записывать любой список.

Разве что кроме использование подлых языков, типа JavaScript, где компилятор, не найдя запятую в конце строки, решает, что программист дебил, и сам ставит точку с запятой.

[alll]

Что стоит - категорически согласен.
Но моё замечание касалось того, что позволяют и чего не позволяют конкретные языки. С++ позволяет запятую в конце списка инициализации массива, но не позволяет - в конце списка параметров функции. И я даже боюсь гадать, какие именно тараканы водятся в головах авторов этого языка и на каких граблях им довелось поплясать в процессе приобретения опыта.

[sab123.livejournal.com]

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

[vit-r.livejournal.com]

 Пишут не для машин, а для людей.
+ а
, а

[sab123.livejournal.com]

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

[vit-r.livejournal.com]

Запятая - это оператор не окончания а продолжения.
Код немного отличается от книги и читают его по одной координате

[alll]

Меня терзают смутные сомнения. В вашем примере инициализация массива или объявление перечисления. А в примере автора заметки - параметры вызова функции.

[sab123.livejournal.com]

В Перле можно и в вызовах функций.

[alll]

Тссс! Сейчас понабигут.

[alll]

Я, конечно, пацифист, но когда вижу конструктор с таким числом параметров, рука тянется к. Потому что это мне придётся читать, смотреть в дебаггере, проверять, добавлять, исправлять и портить. А удобно с этим примером производить всего два действия из вышеперечисленных.

[vit-r.livejournal.com]

Конкретные правила зависят от языка и от прменяемых тулов. Так цветные мониторы и широкие экраны резко изменили вид "правильного" кода.

А так, всё познаётся на опыте.

[alll]

ОК, к двум удобствам широкий экран добавляет третье, но современные дебаггеры обесценивает первое, так что всё-равно остаётся два. :)

К сожалению сколь угодно широкий экран неспособен повлиять на ограничения моего мозга на количество одновременно осознаваемых параметров. Причём характер форматирования в примере показывает, что не только моего. :)

[vit-r.livejournal.com]

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