Как стать автором
Обновить
17
0
Vladislav Zlobin @SCoon

Пользователь

Отправить сообщение
В данном случае «evidence» переводится не как «доказательство» (мы на собираемся никому ничего доказывать), а как «наблюдение».
Увы, этот код не идентичен тернарному оператору из C. По той простой причине, что в Вашем случае ОБА выражения из списка будут вычислены, а в случае C — только нужное.
Версия про Машину Поста интересна. Однако, в действительности тернарный оператор не был придуман в C, а пришел в него уже готовым из CPL, чуть поменяв синтаксис. Там это писалось так:

BooleanExpr -> TrueExpr, FalseExpr


На синтаксис Машины Поста не похоже совершенно.

Основы синтаксиса CPL можно посмотреть в статье "The main features of CPL". Ответ на вопрос «давайте разберемся почему он именно такой, а не другой» нужно искать именно в этой статье. :)

Так что красивое, но совпадение.
При прочтении текста создается ощущение, что «шляпы» нужно использовать в описанном порядка. Это не так.

Кроме того, совершенно незачем выделять отдельного человека в синей шляпе — Вы путаете синюю шляпу с обязанностями модератора. Это не то же самое. Перечитайте в книжке про синюю шляпу.

Что до количества участников — эта схема эффективна даже для единственного участника.
«Точка зрения нашего сообщества была одним из проектируемых преимуществ»

Коллеги, скажите, это вообще перевод на какой язык? Что не на русский — это я и сам понял…
Потому, что так написано в style guide тех проектов, в которых я писал код на C#. А поскольку лично для себя я на C# не пишу, то и потребности пересматривать это у меня нет.
Если бы можно было на ходу менять чужой style guide — проблемы вообще бы не было, не правда ли?
Затем, что в ситуации «делаем отступы только пробелами» Ваш совет вообще теряет всякий смысл. Это я пытался создать ситуацию, когда он хоть как-то применим.
This file is licensed under GPL, www.gnu.org/copyleft/gpl.html

Вероятно, я отстал от современных трендов программирования на C#. А как сейчас принято указывать тип лицензии, по которой распространяется код?
Некоторые — да. Причем уместность того или иного приема будет зависеть от большого количества факторов: степени соответствия общепризнанным стилям кодирования этого языка, степени соответствия общей практике программирования на этом языке, используемых инструментальных средств и их настроек и т.п.

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

Еще пример: открывающая скобка на новой строке повысит читаемость кода, если в данном проекте приняты большие выражения в условном операторе (в коде бизнес-правил легко может быть 7-10 строк в выражении внутри if())

Так что да, эти приемы могут быть применены. Равно как и обратные к ним.
Все эти достоинства будет малоприменимы для программиста, пишущего не C# и не использующего python, не правда ли? Ну кроме спорного «код короче».
Не потому ли так происходит, что стандарт выбирается больше на основе привычек, а не логического анализа с изменением привычки?

Я не участвовал ни в одной рабочей группе, создавший принятый среди большинства разработчиков coding style. А заниматься абстрактными домыслами мне не интересно. Возможно — они следуют привычкам. Возможно — логике. Возможно — это просто результат произвольных решений в ходе политической борьбы внутри рабочей группы. Не имею ни малейшего понятия.

Если у Вас есть достоверная информация — можете ею поделиться, всем будет полезно.

Но если вставить одну табуляцию вместо 4 пробелов, и одну табуляцию вместо двух пробелов?

Итак, у нас есть два coding style. Оба разрешают делать отступы пробелами, табуляциями и любым их сочетанием. В некоторой ситуации X первый стиль требует отступ на 4 пробела, второй — на два. Мы не можем изменить сами описанные в стилях правила.

Я вижу, что Ваше решение будет работать ровно в одном случае: если так совпало, что первый стиль приравнивает таб к 4 пробелам, а второй — к 2. Мне это допущение представляется чересчур натянутым.
Интереснее будет за 3 года перейти на язык, где фигурные скобки не используются для выделения блоков кода. :)
Я имеею образования в области нейрофизиологии, соответственно эта дискуссия — без меня.
Но кто пишет такие стили? Программисты-тимлидеры. А они могут за свою жизнь попробовать много стилей, и к чему они придут в финале, то и будет очередным стандартом.

Вам кажется очевидным, что «в финале» они придут к какому-то единому для себя стандарту. К сожалению, это не более чем произвольная догадка. Лично мой опыт мягко говоря не убеждает меня в ее справедливости.

Не лучше ли использовать табуляции? ))

Why not. Вот только я не очень понимаю, как это решает проблему работы с этими двумя конкретными coding styles — даже в предположении, что в обоих разрешены табуляции.
Там есть и ответ, с которым я согласен:
Ну так это рассуждения, а не доказательство.


Но предположим, что Ваши утверждения верны. А именно:

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


Это полностью соответствует высказанному мной выше мнению:

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


Да, обучение (привычка) позволят мозгу легче распознавать это место. Что никак не изменило характеристик самого текста.

Или Ваш комментарий был оригинальной формой высказать согласие с моей точкой зрения?
Формально — при заявленных им условиях, которые Вы почему-то не отквотили — автор прав. Но практического значения, разумеется, не имеет. Тем более, что там по соседству есть действительно ложное утверждение…
Если стили отличаются не сильно, то и в памяти надо держать меньше отличий. Должно быть легче…

На практике — наоборот. Переключиться между фигурными скобками «на той же — на следующей» радикально проще, чем между «ставим 4 дополнительных пробела или 2, если оператор продолжается на следующей строке» и т.п.

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


Я в принципе не очень понимаю разговоры про универсальный стиль. Устраиваетесь на работу, читаете местный coding style и следуете ему. Здесь нет никакой свободы обычно. Ну разве что всегда искать работу, где будешь единственным программистом.
На Java — на той же. На C# — на следующей.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность