... делятся на 2 типа
Ну тык правильно, меньше строк кода.
12.06.2017, 18:41
Индусский код как понятие в свое время появилось не сколько от кривости кода, сколько от простого факта, что им платили за количество строк. Именно благодаря индусам сейчас есть целые корпоративные требования по разметке и форматированию кода, именно благодаря индусам возникло огромное количество метрик и требований, даже некоторые языки программирования.
К примеру в одной известной синей конторе, которую я не буду называть, в некоторых коммандах по написанию драйверов ввели требование по индексу удовлетворения условий приемки против количества добавленных строк кода. Чем больше функционала реализовано и меньше строк/выражений добавлено, тем больше бонус по окончанию спринта. Результат был одновременно плачевный и fucking win. Плачевно потому что дебаг и сдача проекта другим коммандам - превратилось в адовый брейнфак. Даже требование по синхронному комментированию не помогало. А лютая победа обеспечивалась таким приростом производительности что если версия таки проходила все чеки, то конкурентов уделывали по качеству связи на голову. (правда, потом АНБ юзало мнго много дырок в таком коде, но это уже соооовсем другая история)
К примеру в одной известной синей конторе, которую я не буду называть, в некоторых коммандах по написанию драйверов ввели требование по индексу удовлетворения условий приемки против количества добавленных строк кода. Чем больше функционала реализовано и меньше строк/выражений добавлено, тем больше бонус по окончанию спринта. Результат был одновременно плачевный и fucking win. Плачевно потому что дебаг и сдача проекта другим коммандам - превратилось в адовый брейнфак. Даже требование по синхронному комментированию не помогало. А лютая победа обеспечивалась таким приростом производительности что если версия таки проходила все чеки, то конкурентов уделывали по качеству связи на голову. (правда, потом АНБ юзало мнго много дырок в таком коде, но это уже соооовсем другая история)
Это был сарказм.
Да и операций меньше
Эксперт точно знает ТЗ )
если количество звездочек после релиза вместо 5 может стать 100500, то количество звездочек должно быть параметром для программы. В противном случае, их столько никогда не будет, даже если окажется нужно, потому что "программой такое количество не предусмотрено" (и манал я лесть в исходники только ради этого).
Эксперт бы за такое даже не взялся.
Какой-то злой говноэстет прошелся по комментариям и всем влепил по -1.2
А тем не менее любой человек, хоть раз в жизни работавший на реальной работе, должен понимать, что для одной разовой задачи рентабельнее сделать её вручную, чем потратить время человека и машины на ввод программы в петлю.
То же самое, кстати, касается любого производства, где бывает проще ножовкой, стамеской и наждачкой сделать за две минуты паз в бруске, чем идти на дальний конец склада, раскладывать пилораму, цеплять к ней фрезу, вымерять расстояния...
Проще, сука, взять и сделать за две минуты руками.
А тем не менее любой человек, хоть раз в жизни работавший на реальной работе, должен понимать, что для одной разовой задачи рентабельнее сделать её вручную, чем потратить время человека и машины на ввод программы в петлю.
То же самое, кстати, касается любого производства, где бывает проще ножовкой, стамеской и наждачкой сделать за две минуты паз в бруске, чем идти на дальний конец склада, раскладывать пилораму, цеплять к ней фрезу, вымерять расстояния...
Проще, сука, взять и сделать за две минуты руками.
Всего не предугадать. Возможно ТЗ останется прежним, тогда вариант справа - круче. Возможно, ТЗ поменяется без изменения алгоритма - тогда вариант слева круче, в нём можно просто поменять пределы цикла. А возможно ТЗ поменяется с изменениме алгоритма, например "вместо 2 звездочки в 3 ряду надо рисовать '#'". Тогда опять вариант справа круче. А возможно из ТЗ вообще выкинут этот паттерн, и тогда лучше было вообще не писать, а просто подождать, когда заказчик поменяет мнение (или даже не подождать, а спросить у заказчика "а вам эта хуйня точно нужна? может лучше без неё?").
