Ну тык правильно, меньше строк кода.
И нагляднее.
Индусский код как понятие в свое время появилось не сколько от кривости кода, сколько от простого факта, что им платили за количество строк. Именно благодаря индусам сейчас есть целые корпоративные требования по разметке и форматированию кода, именно благодаря индусам возникло огромное количество метрик и требований, даже некоторые языки программирования.
К примеру в одной известной синей конторе, которую я не буду называть, в некоторых коммандах по написанию драйверов ввели требование по индексу удовлетворения условий приемки против количества добавленных строк кода. Чем больше функционала реализовано и меньше строк/выражений добавлено, тем больше бонус по окончанию спринта. Результат был одновременно плачевный и fucking win. Плачевно потому что дебаг и сдача проекта другим коммандам - превратилось в адовый брейнфак. Даже требование по синхронному комментированию не помогало. А лютая победа обеспечивалась таким приростом производительности что если версия таки проходила все чеки, то конкурентов уделывали по качеству связи на голову. (правда, потом АНБ юзало мнго много дырок в таком коде, но это уже соооовсем другая история)
К примеру в одной известной синей конторе, которую я не буду называть, в некоторых коммандах по написанию драйверов ввели требование по индексу удовлетворения условий приемки против количества добавленных строк кода. Чем больше функционала реализовано и меньше строк/выражений добавлено, тем больше бонус по окончанию спринта. Результат был одновременно плачевный и fucking win. Плачевно потому что дебаг и сдача проекта другим коммандам - превратилось в адовый брейнфак. Даже требование по синхронному комментированию не помогало. А лютая победа обеспечивалась таким приростом производительности что если версия таки проходила все чеки, то конкурентов уделывали по качеству связи на голову. (правда, потом АНБ юзало мнго много дырок в таком коде, но это уже соооовсем другая история)
Это был сарказм.
А разве слева не более правильный вариант ? Да справа более оптимизированный, но если закладываться на то что кол-во звёздочек может быть 100500, то вариант справа китайский код.
справа сразу видно, что делает код, число строчек меньше
Да и операций меньше
Втом то и дело что эксперт всегда знает когда проще прописать в ручную, а когда задать диапазон.
Эксперт точно знает ТЗ )
Явное лучше неявного, поэтому код справа лучше.
Если нужно будет 100500 звёздочек - то нужно будет переписать. Но тоже не так как слева, а, хотя бы, выделить функцию печати n звёздочек.
Если нужно будет 100500 звёздочек - то нужно будет переписать. Но тоже не так как слева, а, хотя бы, выделить функцию печати n звёздочек.
если количество звездочек после релиза вместо 5 может стать 100500, то количество звездочек должно быть параметром для программы. В противном случае, их столько никогда не будет, даже если окажется нужно, потому что "программой такое количество не предусмотрено" (и манал я лесть в исходники только ради этого).
Главное, чтоб работало.
Как правило - да. Но в зависимости от цели и условий задачи, правильным может считаться оба варианта.
Тогда надо написать скрипт, который выводит эти строчки кода 100500 раз в файл main.c
Эксперт бы за такое даже не взялся.
мне, как дизайнеру, больше справа нравится
Слева - на собеседовании, справа - работа.
Какой-то злой говноэстет прошелся по комментариям и всем влепил по -1.2
А тем не менее любой человек, хоть раз в жизни работавший на реальной работе, должен понимать, что для одной разовой задачи рентабельнее сделать её вручную, чем потратить время человека и машины на ввод программы в петлю.
То же самое, кстати, касается любого производства, где бывает проще ножовкой, стамеской и наждачкой сделать за две минуты паз в бруске, чем идти на дальний конец склада, раскладывать пилораму, цеплять к ней фрезу, вымерять расстояния...
Проще, сука, взять и сделать за две минуты руками.
А тем не менее любой человек, хоть раз в жизни работавший на реальной работе, должен понимать, что для одной разовой задачи рентабельнее сделать её вручную, чем потратить время человека и машины на ввод программы в петлю.
То же самое, кстати, касается любого производства, где бывает проще ножовкой, стамеской и наждачкой сделать за две минуты паз в бруске, чем идти на дальний конец склада, раскладывать пилораму, цеплять к ней фрезу, вымерять расстояния...
Проще, сука, взять и сделать за две минуты руками.
а еще лучше сделать 1 printf, чтоб при выводе из разных потоков в куче было, да и вызовов меньше
куда делся "printf is a pattern"?
А еще вывод у правого и левого варианта будет разный из за пробелов
Всего не предугадать. Возможно ТЗ останется прежним, тогда вариант справа - круче. Возможно, ТЗ поменяется без изменения алгоритма - тогда вариант слева круче, в нём можно просто поменять пределы цикла. А возможно ТЗ поменяется с изменениме алгоритма, например "вместо 2 звездочки в 3 ряду надо рисовать '#'". Тогда опять вариант справа круче. А возможно из ТЗ вообще выкинут этот паттерн, и тогда лучше было вообще не писать, а просто подождать, когда заказчик поменяет мнение (или даже не подождать, а спросить у заказчика "а вам эта хуйня точно нужна? может лучше без неё?").
Чтобы написать коммент, необходимо залогиниться