Знаю. Но насколько это важно? Я не помню, чтобы применял инициализацию одних полей класса от других — это опасно, плохой стиль, редко требуется. Еще какие-то побочные эффекты? Поэтому вообще редко меняю порядок переменных с списке инициализации. Думал, что большинство делает так же. В тех проектах, где я участвовал, другие люди тоже вроде не часто меняли эту часть кода.
>сразу видно не вооруженным глазом — это список инициализации
Эта привычка потом часто распространяется и на другие варианты применения — типа запятых перед параметрами функции, если вызов многострочный.
Но когда в разных фирмах разные coding style, хочется выбрать уже какой-то один, чтобы потом не менять привычки. А какой выбрать? Однократно переучится не сложно, но хочется, чтобы после переобучения выбранный стиль был объективно лучше других.
Про энергоэффективность — шутка же. А продуктивность — нет :) Обоснование не внезапное: раз многие люди переходят на скобки на той же строке, что ими движет? Только ли привычка и случайный выбор привычки? А если нет, не попытаться ли распространить то же правило на другие случаи?
Еще одно — попытка дать дополнительную аргументацию для выбора одного стиля кода для всех. Вдруг существует объективно лучший стиль, на который можно переучится, и не будет проблем?
Только если будет затронута последняя строка, у которой запятая не такая, как везде. Неужели редактировать ее приходится настолько часто? Вроде чтение исходников происходит намного чаще, особенно в проектах с многими людьми.
>Мне так читать неудобно. После переобучения не станет лучше.
Откуда известно, что не станет? Мне тоже казалось, что начать ставить скобки на той же строке — всегда будет неудобно. А оказалось наоборот. Многие другие люди тоже переобучились, и теперь понимают, что так лучше.
>Когда сформируете все правила для обоих вариантов — можно будет говорить о количестве правил
Можно рассматривать подмножества правил. В частности, 2 vs 1: «после нового блока не должно быть пустой строки» + «но после начала функции должна быть» vs «после нового блока не должно быть пустой строки». Еще одно 2 vs 1: «новый блок должен отделятся дополнительным отступом», «но к блокам области видимости это не относится» vs «новый блок должен отделятся дополнительным отступом».
>Все, что вы перечислили никоим образом не подтверждает ваш конкретный выбор, о чем я и пытался сказать.
После доводов выше надо еще раз пересмотреть оценку.
C# — скорее традиции, принятые в команде, перенесли еще с Visual C++ — там аналогичные отступы. Поэтому мне на новой работе было и непривычно, что начинал с VC++. Как до того было непривычно менять CamelCase на javaStyle. И уже после этих изменений понял — привычки меняются, их надо перепросматривать, а к выбору подходить рационально.
В последнем случая я тоже за "+" в начале строки. Но "+" в начало потому и ставят, что это — оператор внутри выражения. А запятые, как в параметрах функции или списках инициализации, практически никто не переопределяет, к ним все привыкли. А раз они такие стандартные, то зачем их указывать в начале?
По результатам изменения рейтинга: «If you want to make enemies, try to change something». Даже если изменения рациональны, менять привычки мало кому нравится. А мне менять привычки понравилось — зная, что работоспособность повысится, это делать легко.
Это результат привычки или объективно предопределено особенностями языка? С js у меня мало опыта, а в C# — так это же официальный стиль от Microsoft того требует, не потому ли «так лучше»==«потому что все привыкли»?
Все же не надо преувеличивать, «в одну строку» — такого и близко не было, блочная структура в примерах выше сохраняется. Было наоборот — предложение еще активнее выделять блоки (за счет отступов в областях видимости). Также, новые блоки лучше видны, когда дополнительный отступ появляется не после пустой строки, а после заполненной — так глазам легче увидеть, что был дополнительный отступ. И другие предложения — лишь «нормализовать» стиль, избавится от лишней информации.
1) Краткость — полезное свойство. Если краткость не идет в ущерб удобочитаемости, то стоит однократно переучится. А описанная краткость в ущерб удобочитаемости не идет — после переобучения стало даже лучше.
2) Кроме краткости, еще и унификация. Зачем вводить эти исключения из правил — типа «новый блок с новым отступом, но для public взять на 1 левее»? За счет таких исключений из правил внимание вынуждено удерживать больше данных, навигация по коду становится менее интуитивной — это я сравниваю с тем, что получил после переобучения.
3) Унификация стиля между разными языками программирования. Например, python и С++.
Знаю. Но насколько это важно? Я не помню, чтобы применял инициализацию одних полей класса от других — это опасно, плохой стиль, редко требуется. Еще какие-то побочные эффекты? Поэтому вообще редко меняю порядок переменных с списке инициализации. Думал, что большинство делает так же. В тех проектах, где я участвовал, другие люди тоже вроде не часто меняли эту часть кода.
>сразу видно не вооруженным глазом — это список инициализации
Эта привычка потом часто распространяется и на другие варианты применения — типа запятых перед параметрами функции, если вызов многострочный.
Еще одно — попытка дать дополнительную аргументацию для выбора одного стиля кода для всех. Вдруг существует объективно лучший стиль, на который можно переучится, и не будет проблем?
Откуда известно, что не станет? Мне тоже казалось, что начать ставить скобки на той же строке — всегда будет неудобно. А оказалось наоборот. Многие другие люди тоже переобучились, и теперь понимают, что так лучше.
>Когда сформируете все правила для обоих вариантов — можно будет говорить о количестве правил
Можно рассматривать подмножества правил. В частности, 2 vs 1: «после нового блока не должно быть пустой строки» + «но после начала функции должна быть» vs «после нового блока не должно быть пустой строки». Еще одно 2 vs 1: «новый блок должен отделятся дополнительным отступом», «но к блокам области видимости это не относится» vs «новый блок должен отделятся дополнительным отступом».
>Все, что вы перечислили никоим образом не подтверждает ваш конкретный выбор, о чем я и пытался сказать.
После доводов выше надо еще раз пересмотреть оценку.
2) Кроме краткости, еще и унификация. Зачем вводить эти исключения из правил — типа «новый блок с новым отступом, но для public взять на 1 левее»? За счет таких исключений из правил внимание вынуждено удерживать больше данных, навигация по коду становится менее интуитивной — это я сравниваю с тем, что получил после переобучения.
3) Унификация стиля между разными языками программирования. Например, python и С++.