в инженерной дисциплине существуют критерии оценки качества. вполне конкретные

Был у меня опыт. Пытались договориться, долго долго пиздели о том, как надо делать. Просто ориентиры фундаментально разные. Им было важно, чтобы пустые строчки стояли где надо, и чтобы нейминг соответствовал каким-то странным стандартам. А мне было важно, чтобы нейминг был говорящий, взаимодействия явные и модульность нормальная. Так и не смогли договориться

Такс. Донесу мысль. Плохой и хороший - субъективные понятия

Beauty is in the eye of the beerholder

В теории да.

пойди попробуй сдай в эксплуатацию дом, который не проходит инспекцию. или выпусти автомобиль, в котором софт не проходит критерии MISRA

пойди попробуй сдай в эксплуатацию дом, который не проходит инспекцию. или выпусти автомобиль, в котором софт не проходит критерии MISRA

Да я ж не спорю

да ладно тебе - вон, самолёты даже такие выпускают

737 MAX

то есть критерии все же есть? стало быть, нам надо определиться с критериями для кода

пойди попробуй сдай в эксплуатацию дом, который не проходит инспекцию. или выпусти автомобиль, в котором софт не проходит критерии MISRA

и что не так с софтом в этом самолете?

Ты чо, правда не слышал?

не слышал. слышал, что там системы странно работали, но про софт ничего не было

ничо, что говорят, что проблема будет решена апдейтом софта?

4. Соответствие результата работы заявленному функционалу

5. Идеоматичное выражение целей и задач относительно выбранного языка

Идиоматичное только

А вот эта хуерга на C# - это идеоматичечно?

п.п. 5 и 6 уже сильно зависят от среды, в которой код пишется

Был у меня опыт. Пытались договориться, долго долго пиздели о том, как надо делать. Просто ориентиры фундаментально разные. Им было важно, чтобы пустые строчки стояли где надо, и чтобы нейминг соответствовал каким-то странным стандартам. А мне было важно, чтобы нейминг был говорящий, взаимодействия явные и модульность нормальная. Так и не смогли договориться

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

а аргументы у него были?

ну типа это вообще не понятно для него

для простоты положим, что это Visual Studio на win

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

На хаскелле можно же написать так? 2 `(+)` 2

это очевидно. сейчас мы опять вернемся к “люди бывают разные”

Ты от меня хочешь оценочных суждений, но мне их давать сложно

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

Секиро научило меня парировать

let a = (2, 2) ||> (+)

в общем, в ситуации “все мы разные” и когда никто не пытается хотя бы минимально организовать практики - код проваливается по абсолютно всем критериям, которые мы перечислили

т.к. как ты собрался обеспечивать №2, если на понимание кода ты тратишь полдня и по факту работаешь белковым компилятором?

Здесь вариант, что я попал в чужеродную среду, где мне плохо. Или тот, кто писал этот код, находится в чужеродной среде, и ему плохо

однако это не повод писать херовый код

Скорее это не повод не договариваться об определенных правилах, что считать хорошим, а что плохим

если не вообще *всегда* читаемый код

и вот тут мы находимся буквально в одном шаге от диалектического синтеза

На самом деле в коде всегда работает принцип "все гениальное - просто"

угу. теперь дострой цепочку до “просто - значит легко читается, стало быть хороший код - читаем”