В начале своей карьеры писал как раз надежный протокол поверх UDP для аналога Скайпа, которого тогда не было. Идея была в том, что гарантировалась знание о состоянии канала на обеих его сторонах и возможность управлять передачей (напр., запрашивать недоставленные пакеты).
Но в конце-концов не пошло именно из-за сетей за HTTP-прокси.
Это у них, видимо, так, потому что наемом занимаются люди, которые никакого отношения к тому проекту не имеют. Поэтому у них подход чисто формальный: озадачить кандидата задачкой и поставить оценку, которая зависит от того, насколько его решение соответсвует тому, что они ожидают. Им так проще.
А вот насколько способность быстро решать логические/алгоритмические задачи на интервью кореллирует с практикой разработки программного обеспечения, это еще вопрос. По мне так не сильно.
По поводу того, какой из вариантов труднее воспринимать, думаю смысла нет обсуждать. поскольку это, как я понимаю, уже достаточно высокоуровневая психическая деятельность, и она связана со сформированными привычками и определенными ментальными моделями (а у нас они по видимому отличаются).
Но вот ваше утверждение:
Но восприятие текста гораздо менее важно, чем отсутствие ошибок. Первая задача стиля, как я это вижу, — способствовать минимизации ошибок, а уже потом можно думать над читабельностью.
— я принять не могу. Поскольку оно противоречит само себе.
Невозможно обнаруживать и исправлять ошибки без понимания программы, а оно образуется только как результат восприятия её текста. Поэтому восприятие первично. Вы же обнаружили отсутствие скобки, только после того, как поняли, что это за выражение, не так ли? Вы можете утверждать, например, что ваш вариант легче для восприятия, и поэтому позволяет легче обнаруживать ошибки. И я (теоретически) могу с вами согласиться в этом. Но утверждать, что он позволяет находить ошибки, независимо от того, что может формировать текст трудный для восприятия, я думаю, вы всё-таки не станете.
Моя интерпретация этой синтаксической конструкции отличается от вашей: для меня это вызов функции, который состоит из имени функции и списка аргументов. Аргументы не принадлежат функции, а передаются ей.
По поводу вашего стиля я уже отписывался выше: тут и тут.
В вашем варианте мне нравится то, что есть пробелы. В остальном нет. Почему, вы можете прочитать выше.
Ваши аргументы меня не убеждают, и в целом, на мой взгляд, выражение лучше не выглядит. Кажется каким-то рыхлым. Но спорить не буду. Тот стиль, который я привел, я использую достаточно давно, и он не вызывает у меня отторжения, хотя ничего идеального, конечно, нет. Попробуйте использовать свой стиль хотя бы несколько лет, возможно, вы не будете так категоричны.
Да, я писал про идентификаторы и про важность разделения их пробелами. Мне нужен был пример, но судя по всему, я подобрал его не совсем удачно, поскольку вы уже, как минимум, второй человек который пишет мне про структурированные параметры. Поэтому я его упростил: убрал ненужное приведение типа.
Ошибка со скобкой достаточно показательна. Во-первых, это хороший пример того, что надо использовать правильный инструмент для редактирования, который делает такие ошибки заметными. Чего я не делал по определенным причинам. Но это относится к редактированию, а не к чтению, и в данной статье не рассматривается. Во-вторых, интересно, что мне отсутствие скобки не мешало воспринимать этот фрагмент правильным образом. Но у меня были определенные ожидания. Сильно ли она помешала вам?
Я не вижу здесь какой-то особенной проблемы с интерпретацией этого выражения.
Однако, насколько я вас понимаю, вы пытаетесь сказать мне, что существуют ситуации, когда использование пробелов для разделения идентификаторов может привести привести к такому затруднению.
Если так, то я готов с вами согласиться. Наверно, действительно, существуют такие случаи. Те примеры, которые вы приводили, однако, на мой взгляд, к ним не относятся.
Пробелы облегчают нам чтение идентификаторов, но они же используются для формирования визуальной структуры программы. В случае сложных синтаксических конструкций эти две их функции вполне вероятно могут конфликтовать. В таком случае приходится чем-то жертвовать.
Но это, как мне представляется, достаточно редкие случаи. Пока все что приходит в голову, это шаблоны. Наверно, будет неестественно выглядить, если разделить пробелами имя и описание типа в угловых скобках. Просто потому, что тип воспринимается как продолжение имени.
Ну, получается, что я вас не понял. И сейчас не совсем понимаю. :)
Потому что, как мне кажется, в контексте того, о чем мы говорим (о расстановке пробелов), конкретные имена не важны. Длина важна.
Все то же. Из-за масштаба просто пробелы выглядят большими. Но список аргументов все равно попадает в поле зрения и учитывается при интерпретации выражения.
С вариантом без пробела, тоже, казалось бы, не дожно быть каких-то затруднений при чтении, учитывая малые длины:
result = max * max(min, max)
Но тем не менее при первом взгляде на это выражени у меня лично все равно возникает некоторый дискомфорт из-за слипшихся max(min, которые, если смотреть куда-нибудь в строну result или первого max, воспринимаются как что-то единое, с каким-то возмущением посередине.
result = someFunction (firstArgument, secondArgument);
Здесь пробел разделяет имя функции и список аргументов, то есть подчеркивает структуру этого выражения, то, что функции передается список аргументов. То есть у нас есть два объекта: функция, представляемая её именем, и жестко (за счет прилегающих скобок) связанный список аргументов.
result = someFunction( firstArgument, secondArgument );
А здесь скобка сильнее связана с именем функции, и получается, что фунция получает на список, а отдельные аргументы, и даже как бы не получает, а содержит их что ли. За счет пробелов, формируется ощущение некоторой свободы у аргументов, кажется, что они разбредутся, как овцы в загоне. Список разваливается на отдельные аргументы.
Псеводкод я понял. Да, тут можно так подумать. Но это потому, что код некорректно отформатирован (не отражает структуру программы, действие 6 должно иметь отступ). И плохо написан в том смысле, что действие 6 надо по-хорошему заключать в кавычки.
Как это относится к правилам расстановки фигурных скобок, я так и не понял.
Предлагаю взять паузу и обдумать всё хорошенько. Тем более что по результатам нашей беседы у меня появились две небольшие формулировки, которые может стоить вставить в статью. :) Надо обдумать.
Наверно, такой вариант тоже возможен. Его основной недостаток, на мой взгляд, что он не соответсвует привычкам из естественного языка. Кроме того, на мой взгляд, все-таки скобки ассоциируются со списком аргументов. То есть у нас есть имя функции и список аргументов, ограниченный скобками. Пробел в конце выглядит ненужным, его основная функция придать симметрию выражению в скобках.
В общем, неестественно.
Ну и последний аргумент мне тоже кажется надуманным.
Относительно первой строки. Во-первых, лишний пробел после первой скобки. Он отрывает аргумент от имени функции.
b = a * a (a (a, a), a)
В принципе, я могу увидеть здесь и a * a с хвостом, но с большей легкостью это интерпретируется правильным образом (возможно, потому что я знаю, что это правильно).
Во-вторых, имена короткие. Я бы даже сказал нереально короткие. Размер пробела оказывается большим по сравнению с размерами идентификаторов, и они воспринимаются как далеко отстоящие друг от друга. Да и оператор весит не намного меньше имени. Возможно из-за этого имя легче отрывается от списка аргументов.
Более реальный вариант выглядел бы как-то так:
result = firstOperand * functionName (firstArgument, secondArgument)
Здесь в масштабе имен пробел уже не так весом. При желании, конечно, можно и тут напрячься и проинтерпертировать это как firstOperation * functionName, но мой мозг сопротивляется ("Там же список аргументов!")
Если удалить философию и рассуждения об экперименте, которое не проводилось, то у нас останутся лишь факты, относящиеся к психо-физическим особенностям зрения. А они ничего не говорят нам о том, что мы должны всегда ставить скобки только одним, заранее выбраным способом. По моему, это единственно правильный способ рассужения. :)
Ну, у Мартина я цитирую то, с чем согласен. Проблема в том, что часто те правила, которые приводят «классики», не имеют под собой каких-то ясных объяснений. Я попытался эти правила найти. Цитата, которую вы приводите характерна тем, что в ней автор оперирует такими понятиями как «любимый», то есть он априори говорит лишь о субъективной составляющей, и оставляет в стороне объективные критерии удобочитаемости.
По поводу скобок, если они стоят на своем месте, то есть не вызывают затруднений при чтении и формируют корректную визуальную структуру, то удивления вызывать они не будут. Почему они должны вызывать у вас удивления, если вы готовы к тому, что в ваших правилах есть известные исключения? Расстановка же по жесткому правилу, которое принципиально не способно учесть весь контекст текста, всегда в большей (для 1TBS ) или меньшей (для Allman ) степени будет приводить к неудовлетворительному результату.
Соглашения должны быть, но формироваться они должны на основе понимания того, почему мы объективно должны делать так, а не иначе, а не по праву первого или в результате простого следования тому, что пишут «классики».
В начале своей карьеры писал как раз надежный протокол поверх UDP для аналога Скайпа, которого тогда не было. Идея была в том, что гарантировалась знание о состоянии канала на обеих его сторонах и возможность управлять передачей (напр., запрашивать недоставленные пакеты).
Но в конце-концов не пошло именно из-за сетей за HTTP-прокси.
Это у них, видимо, так, потому что наемом занимаются люди, которые никакого отношения к тому проекту не имеют. Поэтому у них подход чисто формальный: озадачить кандидата задачкой и поставить оценку, которая зависит от того, насколько его решение соответсвует тому, что они ожидают. Им так проще.
А вот насколько способность быстро решать логические/алгоритмические задачи на интервью кореллирует с практикой разработки программного обеспечения, это еще вопрос. По мне так не сильно.
Теперь стало известно, чего им все это стоило: https://twitter.com/StanTwinB/status/1336890442768547845
По поводу того, какой из вариантов труднее воспринимать, думаю смысла нет обсуждать. поскольку это, как я понимаю, уже достаточно высокоуровневая психическая деятельность, и она связана со сформированными привычками и определенными ментальными моделями (а у нас они по видимому отличаются).
Но вот ваше утверждение:
— я принять не могу. Поскольку оно противоречит само себе.
Невозможно обнаруживать и исправлять ошибки без понимания программы, а оно образуется только как результат восприятия её текста. Поэтому восприятие первично. Вы же обнаружили отсутствие скобки, только после того, как поняли, что это за выражение, не так ли? Вы можете утверждать, например, что ваш вариант легче для восприятия, и поэтому позволяет легче обнаруживать ошибки. И я (теоретически) могу с вами согласиться в этом. Но утверждать, что он позволяет находить ошибки, независимо от того, что может формировать текст трудный для восприятия, я думаю, вы всё-таки не станете.
Моя интерпретация этой синтаксической конструкции отличается от вашей: для меня это вызов функции, который состоит из имени функции и списка аргументов. Аргументы не принадлежат функции, а передаются ей.
По поводу вашего стиля я уже отписывался выше: тут и тут.
В вашем варианте мне нравится то, что есть пробелы. В остальном нет. Почему, вы можете прочитать выше.
Ваши аргументы меня не убеждают, и в целом, на мой взгляд, выражение лучше не выглядит. Кажется каким-то рыхлым. Но спорить не буду. Тот стиль, который я привел, я использую достаточно давно, и он не вызывает у меня отторжения, хотя ничего идеального, конечно, нет. Попробуйте использовать свой стиль хотя бы несколько лет, возможно, вы не будете так категоричны.
Да, я писал про идентификаторы и про важность разделения их пробелами. Мне нужен был пример, но судя по всему, я подобрал его не совсем удачно, поскольку вы уже, как минимум, второй человек который пишет мне про структурированные параметры. Поэтому я его упростил: убрал ненужное приведение типа.
Ошибка со скобкой достаточно показательна. Во-первых, это хороший пример того, что надо использовать правильный инструмент для редактирования, который делает такие ошибки заметными. Чего я не делал по определенным причинам. Но это относится к редактированию, а не к чтению, и в данной статье не рассматривается. Во-вторых, интересно, что мне отсутствие скобки не мешало воспринимать этот фрагмент правильным образом. Но у меня были определенные ожидания. Сильно ли она помешала вам?
Я не вижу здесь какой-то особенной проблемы с интерпретацией этого выражения.
Однако, насколько я вас понимаю, вы пытаетесь сказать мне, что существуют ситуации, когда использование пробелов для разделения идентификаторов может привести привести к такому затруднению.
Если так, то я готов с вами согласиться. Наверно, действительно, существуют такие случаи. Те примеры, которые вы приводили, однако, на мой взгляд, к ним не относятся.
Пробелы облегчают нам чтение идентификаторов, но они же используются для формирования визуальной структуры программы. В случае сложных синтаксических конструкций эти две их функции вполне вероятно могут конфликтовать. В таком случае приходится чем-то жертвовать.
Но это, как мне представляется, достаточно редкие случаи. Пока все что приходит в голову, это шаблоны. Наверно, будет неестественно выглядить, если разделить пробелами имя и описание типа в угловых скобках. Просто потому, что тип воспринимается как продолжение имени.
Вы про имена с подчеркиваниями?
Ну, получается, что я вас не понял. И сейчас не совсем понимаю. :)
Потому что, как мне кажется, в контексте того, о чем мы говорим (о расстановке пробелов), конкретные имена не важны. Длина важна.
Все то же. Из-за масштаба просто пробелы выглядят большими. Но список аргументов все равно попадает в поле зрения и учитывается при интерпретации выражения.
С вариантом без пробела, тоже, казалось бы, не дожно быть каких-то затруднений при чтении, учитывая малые длины:
Но тем не менее при первом взгляде на это выражени у меня лично все равно возникает некоторый дискомфорт из-за слипшихся
max(min, которые, если смотреть куда-нибудь в стронуresultили первогоmax, воспринимаются как что-то единое, с каким-то возмущением посередине.Вот ещё момент.
Здесь пробел разделяет имя функции и список аргументов, то есть подчеркивает структуру этого выражения, то, что функции передается список аргументов. То есть у нас есть два объекта: функция, представляемая её именем, и жестко (за счет прилегающих скобок) связанный список аргументов.
А здесь скобка сильнее связана с именем функции, и получается, что фунция получает на список, а отдельные аргументы, и даже как бы не получает, а содержит их что ли. За счет пробелов, формируется ощущение некоторой свободы у аргументов, кажется, что они разбредутся, как овцы в загоне. Список разваливается на отдельные аргументы.
Ох и ах. Фигурные скобки, конечно.
Псеводкод я понял. Да, тут можно так подумать. Но это потому, что код некорректно отформатирован (не отражает структуру программы, действие 6 должно иметь отступ). И плохо написан в том смысле, что действие 6 надо по-хорошему заключать в кавычки.
Как это относится к правилам расстановки фигурных скобок, я так и не понял.
Предлагаю взять паузу и обдумать всё хорошенько. Тем более что по результатам нашей беседы у меня появились две небольшие формулировки, которые может стоить вставить в статью. :) Надо обдумать.
Наверно, такой вариант тоже возможен. Его основной недостаток, на мой взгляд, что он не соответсвует привычкам из естественного языка. Кроме того, на мой взгляд, все-таки скобки ассоциируются со списком аргументов. То есть у нас есть имя функции и список аргументов, ограниченный скобками. Пробел в конце выглядит ненужным, его основная функция придать симметрию выражению в скобках.
В общем, неестественно.
Ну и последний аргумент мне тоже кажется надуманным.
Относительно первой строки. Во-первых, лишний пробел после первой скобки. Он отрывает аргумент от имени функции.
В принципе, я могу увидеть здесь и
a * aс хвостом, но с большей легкостью это интерпретируется правильным образом (возможно, потому что я знаю, что это правильно).Во-вторых, имена короткие. Я бы даже сказал нереально короткие. Размер пробела оказывается большим по сравнению с размерами идентификаторов, и они воспринимаются как далеко отстоящие друг от друга. Да и оператор весит не намного меньше имени. Возможно из-за этого имя легче отрывается от списка аргументов.
Более реальный вариант выглядел бы как-то так:
Здесь в масштабе имен пробел уже не так весом. При желании, конечно, можно и тут напрячься и проинтерпертировать это как
firstOperation * functionName, но мой мозг сопротивляется ("Там же список аргументов!")Прошу прощения, вопрос не понял.
Если удалить философию и рассуждения об экперименте, которое не проводилось, то у нас останутся лишь факты, относящиеся к психо-физическим особенностям зрения. А они ничего не говорят нам о том, что мы должны всегда ставить скобки только одним, заранее выбраным способом. По моему, это единственно правильный способ рассужения. :)
Не понимаю, что сравнить, но если выбрать из того, что есть, то последний.
Ну, у Мартина я цитирую то, с чем согласен. Проблема в том, что часто те правила, которые приводят «классики», не имеют под собой каких-то ясных объяснений. Я попытался эти правила найти. Цитата, которую вы приводите характерна тем, что в ней автор оперирует такими понятиями как «любимый», то есть он априори говорит лишь о субъективной составляющей, и оставляет в стороне объективные критерии удобочитаемости.
По поводу скобок, если они стоят на своем месте, то есть не вызывают затруднений при чтении и формируют корректную визуальную структуру, то удивления вызывать они не будут. Почему они должны вызывать у вас удивления, если вы готовы к тому, что в ваших правилах есть известные исключения? Расстановка же по жесткому правилу, которое принципиально не способно учесть весь контекст текста, всегда в большей (для 1TBS ) или меньшей (для Allman ) степени будет приводить к неудовлетворительному результату.
Соглашения должны быть, но формироваться они должны на основе понимания того, почему мы объективно должны делать так, а не иначе, а не по праву первого или в результате простого следования тому, что пишут «классики».
К сожалению, даже с результатами исследований, в большинстве случаев результат будет тот же.