Здравствуйте, so5team, Вы писали:

S>Здравствуйте, CreatorCray, Вы писали:

S>>>приходится перестраивать мозги на то, чтобы понять и принять стиль именования.
CC>>Как тебе это удаётся?
S>За счет превозмогания, конечно же.
Бедняга! Все просто читают а тебе прям аж об колено ломать себя приходится каждый раз.

S>Как я уже говорил, пробелы и скобочки (особенно скобочки) -- это вообще ерунда, на это быстро перестаешь обращать внимания.
Не, как раз это больше всего и раздражает.

S>Вы серьезно думаете, что что-то поменяли?
Код стал читабельнее.

S>вы послали лесом чужой стиль именования сущностей.
Тех, кто разницу в именах делает не в начале а в конце — на вилы и на сковородку.

S>Хотя для персонажей, ставящих пробел перед скобкой, должен быть отдельный котел в аду
Есть одно только "но" — я там буду с вилами.

Здравствуйте, Alekzander, Вы писали:

A>Вот всегда так. Сначала: "Нам IDE всё показывает!", а сами пишут m_.
Потому что это позволяет легко сузить scope для intellisense подсказок при наборе имени переменной, в саааамом начале набора её имени.

Здравствуйте, so5team, Вы писали:

S>Плохо то, что в том же C++ одинаковости нет от слова совсем
Это как раз хорошо. Язык в котором тебе сразу вешают гири на ноги достоен лишь "помоечки где бамжы" (tm)

Здравствуйте, CreatorCray, Вы писали:

S>>>>приходится перестраивать мозги на то, чтобы понять и принять стиль именования.
CC>>>Как тебе это удаётся?
S>>За счет превозмогания, конечно же.
CC>Бедняга! Все просто читают а тебе прям аж об колено ломать себя приходится каждый раз.

Ага, и это вызывает зависть к условным Ruby-истам и Rust-оманам, за которых уже все решили и показали как правильно строем ходить.

S>>Как я уже говорил, пробелы и скобочки (особенно скобочки) -- это вообще ерунда, на это быстро перестаешь обращать внимания.
CC>Не, как раз это больше всего и раздражает.
Бедняга! Все просто читают а тебе прям аж об колено ломать себя приходится каждый раз.

S>>Вы серьезно думаете, что что-то поменяли?
CC>Код стал читабельнее.

Допустим. Но все равно там мешанина из стилей именования сущностей. Которой нет в том же Rust-е, к примеру.

Здравствуйте, CreatorCray, Вы писали:

S>>Плохо то, что в том же C++ одинаковости нет от слова совсем
CC>Это как раз хорошо. Язык в котором тебе сразу вешают гири на ноги достоен лишь "помоечки где бамжы" (tm)

Поскольку предыдущий оратор оставил вопрос без ответа, то попробую задать его вам:

Ну выкиньте тот же JavaScript вместе с TypeScript. Или Python.

Образовавшиеся лакуны чем заполнять будете?

Вообще-то, если я правильно представляю себе логику развития массовых производств, чем дальше развивается производство, тем важнее становятся унификация и стандартизация.

Вот хотя бы на примере зарядок для мобильных телефонов это можно увидеть: от кучи несовместимых друг с другом разъемов к USB (сперва Micro, теперь Type-C). Хуже от этого разве что Apple стало

Здравствуйте, CreatorCray, Вы писали:

N>>А это и есть чистая практика.
CC>Практика тоже разная бывает. Одни пользуются нормальными тулами и горя не знают, другие по заветам предков колбасят в ed.

То есть твои знания о других доменах и условиях устарели лет... даже не на 40, а на 50 — если ты вспоминаешь ed. Потому что 40 лет назад был уже классический vi.

Ну и понять, почему и где "нормальные тулы" могут быть просто непригодны, ты не хочешь.

Ясненько (c)

N>>Ты действительно не знаешь, что memset не только нулями может заливать, или притворяешься?
CC>Девелоплю с прошлого века, но вот чота случаев чтоб надо было залить ненулевым побайтовым паттерном можно сосчитать на пальцах.
CC>Порылся в сурсах и нашёл ровно одно место: в имплементации MersenneTwister

Достаточно вспомнить отладочную заливку — для которой есть несколько типовых значений.

Здравствуйте, netch80, Вы писали:

A>>В Windows GetVersion() инвертирует порядок major-minor, и почему? А потому, что на каком-то древнем 8086 компилятор для MS-DOS мог СЭКОНОМИТЬ БАЙТ! А потом в дело вступила обратная совместимость.

N>Это просто смешно, потому что номера версий Windows — это отдельное пространство по сравнению с номерами версий DOS.

Если вспомнить, что изначально Windows был надстройкой над DOS, не вижу ничего смешного, что они хотели максимальной совместимости на уровне системных вызовов. Ну представь, на дворе 1988 год, у тебя готовый код для парсинга версий из досовской программы, ты будешь внимательно перечитывать справку (которой, кстати, в 1988 году ещё толком нет, MSDN на дисках впервые вышел в сентябре 1992-ого), чтобы узнать, не изменили ли, часом, порядок следования при сохранении сигнатуры? Мне, скорее, вот это смешно.

И если бы Microsoft сохранил то трепетное отношение к совместимости, я бы и сейчас находился под четырёхпольным флагом.

A>> Может, я, конечно, чего-то путаю, но разве заполнение стека не будет дешевле разыменования указателя? Это если указатель на структуру передавать, и ничего не копировать.
N>Дешевле. Но по сравнению со всеми действиями по открытию файла — сходить N раз к диску — это мелочи.

WinAPI это не только операции с файлами. Я надеюсь, ты ещё помнишь, что в минимальных требованиях у Windows 3.0 (!!! — не какие-нибудь ранние выкидыши, а уже сформировавшаяся на уровне API винда) был указан процессор 8086/8088?

A>>Нормальный наезд! Они сделали стандарт де-факто потому, что им продукт для конечных пользователей надо было срочно выпускать, а стандарта де-юре не было. Сделали, и тут же ПОДАВЛЯЮЩЕЕ большинство пользователей начало им пользоваться. Пришла пора стандартизировать, Microsoft объяснила, что так, мол, и так, это стандарт де-факто, просим зафиксировать. Но комитетчики, не согласуясь со здравым смыслом, приняли свою версию, основанную ни на чём. (Кроме ненависти к Microsoft).

N>Ээээ а можно подробности? Почему вы считаете, что именно "из ненависти к Microsoft?"

Моё предположение. Я не знаю просто, чем ещё можно руководствоваться, чтобы пренебречь фактическим стандартом с подавляющим большинством пользователей.

N>(Даже если эта ненависть оправданна, учитывая её политику всё время существования.)
N>Есть ссылки с описанием истории?

Есть, но это очередная история из серии "Реймонд Чен отвечает злопыхателям". Если его аргументы смешат, лучше найти альтернативный обзор, а потом мы сравним.

Здравствуйте, netch80, Вы писали:

A>>>В Windows GetVersion() инвертирует порядок major-minor, и почему? А потому, что на каком-то древнем 8086 компилятор для MS-DOS мог СЭКОНОМИТЬ БАЙТ! А потом в дело вступила обратная совместимость.

P>>За всё время они так и не смогли выдать внятное апи для проверки версий, фич итд.

N>Какие учителя и коллеги, такие и они.
N>Intel сделал CPUID только когда пошла угроза их торговой марке и им потребовалось, чтобы процессор писал "GenuineIntel" (просто Intel им не хватало).

Боже.

Ты знаешь, какой скандал был, когда они эту фичу представили? PIII чуть не отменили! (В социальном смысле). Это сейчас юзеры свои трусы, переписку, хистори браузера и т.п. добровольно сдают всем крупным компаниям и правительствам одновременно. А тогда компьютеры покупали инженеры, и им не нравилось, что их могут однозначно идентифицировать при помощи процессора.

Здравствуйте, Alekzander, Вы писали:

P>>>За всё время они так и не смогли выдать внятное апи для проверки версий, фич итд.

N>>Какие учителя и коллеги, такие и они.
N>>Intel сделал CPUID только когда пошла угроза их торговой марке и им потребовалось, чтобы процессор писал "GenuineIntel" (просто Intel им не хватало).

A>Боже.

A>Ты знаешь, какой скандал был, когда они эту фичу представили? PIII чуть не отменили! (В социальном смысле).

Ты с прямым углом перепутал.
То что ты говоришь — так называемый processor serial number. Да, это PIII.
А CPUID с текстовой надписью появился в Pentium первом.
Разница в 6 лет.
Может, попробуешь внимательнее читать?

Здравствуйте, Alekzander, Вы писали:

N>>Это просто смешно, потому что номера версий Windows — это отдельное пространство по сравнению с номерами версий DOS.

A>Если вспомнить, что изначально Windows был надстройкой над DOS, не вижу ничего смешного, что они хотели максимальной совместимости на уровне системных вызовов.

Её не было изначально, что там сохранять?
Windows 1.0 была надстройкой над MS-DOS версии не менее 5.0 (точнее не скажу).
3.1 ставилась поверх 6.чего-то (у нас чаще всего была 6.22).
Windows 95, которая внутри себя содержала уже свой DOS, обозначала себя 4.1, а её же DOS был 7.0.
О какой совместимости чего тут вообще могла идти речь?

A> Ну представь, на дворе 1988 год, у тебя готовый код для парсинга версий из досовской программы,

Который неприменим по определению.

A>вот это смешно.

Вот с этой частью фразы точно согласен.

A>И если бы Microsoft сохранил то трепетное отношение к совместимости, я бы и сейчас находился под четырёхпольным флагом.

Ну да, то-то минимальные требуемые ресурсы всё время росли. Ты сам про 3.0 сказал — а 3.1 уже на 8086 не запускалась.

A>>> Может, я, конечно, чего-то путаю, но разве заполнение стека не будет дешевле разыменования указателя? Это если указатель на структуру передавать, и ничего не копировать.
N>>Дешевле. Но по сравнению со всеми действиями по открытию файла — сходить N раз к диску — это мелочи.

A>WinAPI это не только операции с файлами. Я надеюсь, ты ещё помнишь, что в минимальных требованиях у Windows 3.0 (!!! — не какие-нибудь ранние выкидыши, а уже сформировавшаяся на уровне API винда) был указан процессор 8086/8088?

Я говорил в контексте операций с файлами потому, что их специфика была в основной контексте. Ну ещё процессы.
А 3.0 на 86-м процессоре... мало ли что они там указывали. Работать на таком можно было только или запуская одну крошечную программу, или если тот 86-й был оснащён платой EMS расширителя. Иначе банально не хватало ресурсов.
На 386-м через XMS можно было уже избежать постоянной перегонки данных, чем все и пользовались.

N>>Ээээ а можно подробности? Почему вы считаете, что именно "из ненависти к Microsoft?"
N>>(Даже если эта ненависть оправданна, учитывая её политику всё время существования.)
N>>Есть ссылки с описанием истории?

A>Есть, но это очередная история из серии "Реймонд Чен отвечает злопыхателям". Если его аргументы смешат, лучше найти альтернативный обзор, а потом мы сравним.

"Не в лотерею, а в покер, не выиграл, а проиграл, не сто тысяч, а миллион" (c)

Во-первых, это не про стандарт Unicode, а про Unicode спецификаторы в printf-like семействе в C.

Во-вторых... C99 Rationale ничего про это не говорит, увы. Но логика стандартизаторов, думаю, понятна. Спецификаторы должны соответствовать своим типам, а не каким-то непонятным химерам. Есть char — ему %s, есть wchar_t — ему %ls (жаль, что не %ws, ну уж как получилось).
Если бы Microsoft рядом с _TCHAR ввёл %Tc и %Ts какие-нибудь, чтобы ему соответствовали, а про %s сказал бы "неведома зверушка, мы не одобряем", было бы понятно. А так они сами заложили мину под себя.
Ну а поскольку в комитете не только они, а ещё много игроков включая Sun, Apple, IBM, ещё десяток звучных имён — судьба нестандартного загиба MS стала понятна.

Вообще не надо думать, что комитеты как-то однозначно несправедливы к кому-то конкретно. Вот например POSIX интерфейс работы с сигналами процессов не соответствовал ни BSD ни SysV, а вместо этого комитет наработал полностью новые функции (sigaction, sigprocmask, и прочее), потому что общая база просто не могла быть выработана на базе кого-то одного. Есть ещё случаев.

Здравствуйте, netch80, Вы писали:

P>>>>За всё время они так и не смогли выдать внятное апи для проверки версий, фич итд.

N>>>Какие учителя и коллеги, такие и они.
N>>>Intel сделал CPUID только когда пошла угроза их торговой марке и им потребовалось, чтобы процессор писал "GenuineIntel" (просто Intel им не хватало).

A>>Боже.

A>>Ты знаешь, какой скандал был, когда они эту фичу представили? PIII чуть не отменили! (В социальном смысле).

N>Ты с прямым углом перепутал.
N>То что ты говоришь — так называемый processor serial number. Да, это PIII.
N>А CPUID с текстовой надписью появился в Pentium первом.
N>Разница в 6 лет.
N>Может, попробуешь внимательнее читать?

Да, это разные вещи, перепутал, прошу прощения.

Здравствуйте, netch80, Вы писали:

N>О какой совместимости чего тут вообще могла идти речь?

MS-DOS has a Get Version system call
...
Windows adopted the version numbering scheme from MS-DOS

N>Во-первых, это не про стандарт Unicode, а про Unicode спецификаторы в printf-like семействе в C.

Я, вроде, нигде не писал, что про весь стандарт. Я написал:

>Юникод, который они имплементировали "нестандартно"

Имея в виду как раз эти %s/%S.

P.S. Вообще, это упоминание противостояния MS и языковых комитетов приехало сюда из темы про упоротый C++, где было понятно, что речь идёт о языковой фиче. Возможно, надо было уточнить.

CC>Очень далеко не всегда. Когда весь код единообразно отвратительно отформатирован читать эту кашу ничуть не легче.
CC>Более того, хорошо читаемый код как раз отформатирован совсем не единообразно, а как раз с сознательными отступлениями от правил там, где это облегчает чтение.
CC>Жёсткий же автоматический форматтер читабельность только портит.
DE>>А "диктатура" компилятора/форматтера помогает...
CC>... сделать плохо всем и везде.


Подписываюсь под каждым словом.

ЗS>Я так понимаю, что мир Си и C++ вы покинули давным-давно.

Как бы я хотел, чтобы это было правдой! Нет, увы, и на С, и на С++ я все еще вынужден периодически писать. Пусть не так много как раньше, но — достаточно. А уж читать и вовсе приходится десятками тысяч строк. Поэтому я особенно сильно ратую за читабельность (в отличие от писабельности).

ЗS>Можно полюбопытствовать в каких из используемых сейчас вами языках нет строгих требований к именованию сущностей? В Erlang, в Java, в C#?

Не совсем понимаю вопрос. В Erlang, пожалуй, самые строгие требования — имена переменных начинаются с большой буквы.

S>Если все одинаково (и у этой одинаковости есть стройность и логичность), то привыкнуть можно ко всякому

Что значит "привыкнуть"? Как бы я ни "привыкал", скорость осознания происходящего (что и есть аналог "читабельности") будет ниже, чем в отсутствие этой одинаковости. Приведу простую аналогию: бежать с небольшим уклоном то вверх, то вниз (rolling hills) намного быстрее и приятнее, чем в одинаковый на всем протяжении 15% подъем.

N>Я много лет предпочитал для себя писать в стиле
N>if( foo( a + b *( c — d ) ) )

Cтиль, мягко говоря, непривычный, но у меня не возникло никаких проблем распарсить. Достаточно просто и понятно. В отличие от идиотизма с "каждый параметр на своей строчке", так что function declaration занимает 18 строк (из них 8 — спека функции, еще 10 — собственно заголовок, у функции 5 параметров и возврат tuple с 3 элементами).

N>Обычно, когда есть принудительное форматирование, всем одинаково немного неудобно — но, одинаково.

Именно это и обсуждается.

N>На одной из последних работ так и писали. "Мы вводим принудительный прогон всего Python кода через Black. Мы пересмотрели десяток форматтеров и выбрали этот потому, что у него минимум настроек и не о чем вообще спорить."
N>В крупном коллективе часто иначе и не получится.

Теперь внимание, вопрос: а напуркуа? Хоть одно доказательство улучшения хоть по одному параметру (кроме оптимизации зарплаты "внедрятеля форматтеров", само собой) есть?

А вот недовольство программистов однозначно. И недовольство это гарантированно снижает производительность оных программистов.

N>А я попрошу таки пояснительную бригаду, что вам именно тут не понравилось и как предпочитаете взамен.

Предложу взамен так:

some_type_name first_var, second_var, third_var;

Если по каким-то странным причинам "some_type_name" занимает 80 символов, и это один тип (а не композит типа org.java.package.name.from.another.assembly.with.long.namespace, который можно попросту импортировать), тогда так:

typedef org.java.package.name.from.another.assembly.with.long.namespace shorter_type;

shorter_type first_var, second_var, third_var;

Здравствуйте, Alekzander, Вы писали:

A>Боже.

A>Ты знаешь, какой скандал был, когда они эту фичу представили? PIII чуть не отменили! (В социальном смысле). Это сейчас юзеры свои трусы, переписку, хистори браузера и т.п. добровольно сдают всем крупным компаниям и правительствам одновременно. А тогда компьютеры покупали инженеры, и им не нравилось, что их могут однозначно идентифицировать при помощи процессора.

Вот здесь нужно умение компании работать с аудиторией.

N>А то если я например вижу

N>

N>case foo(A, B) of
N>  {ok, Moo} -> process_moo();
N>  {error, Error} -> ... ветчина и ржавчина ...
N>end;
N>

Потому что здесь ты все так же имеешь return codes. Пусть и завернутые в tuples/classes, — это сейчас весьма распространенный подход, и в Rust, и даже в C# (ASP.NET Core, тот самый IActionResult).

Для читабельности кода он должен показывать только success path. Никаких ok и error.

Moo = foo(A, B),
process_moo(Moo)

Или даже короче: process_moo(foo(A, B)). Все. Очень коротко, очень лаконично, очень понятно. Если таких вызовов вложено штук 20, читать все еще просто и понятно.

Почему это реально работает? Потому что НАСТОЯЩАЯ обработка ошибок (будь до скинуть данные в лог и продолжить работу, или сдохнуть с грохотом и искрами, или ответить "не шмогла") все равно осуществляется только на одном уровне (ну, может на двух). Причем уровень этот обычно в какой-нибудь библиотеке (да вот в том же OTP), так что прикладному программисту думать об этом не требуется. Итоговый код выглядит вот так:

my_rpc_method(Arg1, Arg2) ->
    try
        Step1 = outer(Arg1),
        Step2 = middle(Step1, Arg2),
        tail(Step2)
    catch
        throw:{bad_luck, FuncState} ->
            log("здесь логируем то самое состояние функции FuncState")
    end.

outer(Arg1) when is_list(Arg1) ->
   <...>.

middle(Arg1, Arg2) ->
   FuncState = do_some_calc(Arg1, Arg2),
   check_some_condition(Arg1) andalso throw({bad_luck, FuncState).

tail(Arg) ->
    ...

Мне довольно часто приходится объяснять, что приведенный ниже код ОБРАБОТКОЙ ошибок не является:

case foo(A, B) of
    {error, Reason} -> 
        log("bad stuff happened calling Foo, expected Moo got ~p", [Reason]),
        {error, {error_in_foo, Reason}}

Более того, этот ужасный паттерн, который я называю bubble wrap (не знаю, есть ли такой термин официально, но я его всегда использовал), по сути занимается воссозданием call stack внутри того самого return code (возвращаемый tuple).

Еще ужаснее паттерн выглядит, если вместо возврата такого самодельного call stack мы создаем какие-нибудь side effects — те самые "записи в лог". Почему ужаснее — тема отдельного разговора. Вкратце: любые side effects слишком часто ломаются (лог не пишется, или жестко семплируется, или не долетает до центрального сервера, или получает большой amplification factor при постоянном стриминге таких ошибок).

Надеюсь, я смог объяснить, как вообще создатели exceptions дошли до жизни такой. Они просто канонизировали то, что каждый разработчик пытается переизобрести

N>Вообще как-то вспомнился Фортран, там есть для этого очень красивое средство — "alternate RETURN" — назначаемые GOTO-метки, которые можно было передавать в подпрограммы.
N>Я так подозреваю, структурированная обработка исключений родилась из чего-то подобного но с требованием перейти к подходам "структурного программирования" вместо goto.

Именно так я и думаю. Исключения придуманы как средство non local return, с поддержкой самых ценных свойств. Например, если ДЕЙСТВИТЕЛЬНО нужно добавить какие-то очень важные параметры по пути пролета исключения из нижних слоев в верхние, это таки можно сделать (а потом rethrow исключение, сохраняя исходный стек). Это может требоваться в языках, которые слишком полагаются на side effects.

N>А то это огроменный кусок работы, фактически добавляется часть IDE в вебе.

Правильно! Добавление IDE в веб — это как раз самый что ни на есть тренд.

N>Я не понимаю, что это за "прыжки туда-сюда". Сложно два-три таба открыть?

Два еще может и ничего, но обычно если такой паттерн (хелпер-функции) принят, его начинают abuse'ить, и окон уже получается десяток. А потом появляются хелперы-для-хелперов...

N>Заглянуть куда-то кроме места изменения это вообще норма. Например, там вызов чего-то из системного API чего ты никогда ещё не пользовал. Ты закроешь окно ревью, откроешь с функцией API, потом откроешь ревью обратно?

Не, я в таких случая уже начинаю смотреть не в код, а в тесты. В отличие от многих ревьюеров, я и ревьюить-то начинаю зачастую не с кода, а именно с тестов (если их нет, и в патче не объясняется, как же это протестировать, — сразу вопрошаю "как мне это протестировать").

N>В таких местах вообще не во врапперах дело. Но если он меняется в том же ревью, то ты это увидишь.

В предыдущей компании гайдлайны были "разделяй диффы на маленькие порции", и почти всегда хелперы-врапперы шли отдельными диффами. Объяснение — "так проще ревьюить" (ну и порой в самом деле так безопаснеее деплоить, особенно если враппер уже где-то используется). У меня нет strong opinion на эту тему. Хотя в целом я согласен с идеей отделения рефакторинга (а изменение враппера это именно что рефакторинг) от внедрения нового функционала.

S>Ну выкиньте тот же JavaScript вместе с TypeScript. Или Python.

Мужик! А ведь это не мысль! Это — ИДЕЯ!!! (С) Анекдот.