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

Pzz>Ну так всюду и не надо. Предполагается, что человек — разумное существо.
Ну так а теперь отлистай назад и посмотри с чего началось.

S>>Ещо один аргумент против автотипов.
Pzz>Против C++, он весь такой
Сочувствую.

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

Pzz>Тип может быть выведен из констант.

Константа в строго типизированном языке однозначно указывает тип.

Pzz> Или из типа той функции, которая принесла изначальное значение переменной.

Но в самой функции тип то будет.

Pzz>Посмотри на какой-нибудь Хаскель, там очень редко встречается явное указание типа.

Хаскел — экспериментальный язык, поэтому приводить в пример его надо очень аккуратно.

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

НС>>У тебя часто так бывало, что int стал float? У тебя вообще часто тип float в программах встречается? Какой процент от общего количества использований типов составляет float?
Pzz>В JS такое бывает. Там все числа — float.

Мы тут говорили про статическую типизацию.

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

S>Тип тоже влияет на читабельность.

Каким образом?

S>Точно так же придётся по коду гулять чтобы выяснить тип как ты гулял с именами.

Зачем? Нормальный редактор сам подскажет, какой тип у переменной. Вот когда видишь странные имена, становится не до типов.

S>При том

Автор: Философ
Дата: 03.05.22

— последняя фраза. Так как для рефакторинга есть инструменты, то остаётся только предположить что "некрасивые длинные диффы".

По ссылке с последней фразой все в порядке. Приходилось мне тип возвращаемого значения менять. И еще кое-что делать. Без var я бы запарился код чинить.

S>auto вообще с здравым смыслом несовместимо.

Обоснуй. Либо речь идет о каком-то особенном здравом смысле. Я в шарпе var использую постоянно. И никаких проблем не испытываю. Правда, поддержка шарпа со стороны студии получше, чем плюсов.

S>Где удобно, я так и писал. Но не везде подряд.

Локальным переменным удобнее выволить тип автоматически в подавляющем большинстве случаев. Особенно если тип длинный, с шаблонами (в моем случае с generic-ами). Кстати, вдруг в процессе тестирования выяснится, что в данном месте лучше применить список вместо вектора, c использованием var такой переход пройдет намного менее напряжно, чем с ручной заменой вектора на список по всем местам. Да еще всегда есть шанс что-то упустить. Компилятор, конечно, пропуск обнаружит, но все равно время уйдет.

P>>Ты точно не путаешь var с dynamic? Или что там в плюсах, голый void-указатель?
S>Точно.

Судя по твоим сообщениям, таки путаешь.

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

S>>Точно так же придётся по коду гулять чтобы выяснить тип как ты гулял с именами.

P>Зачем? Нормальный редактор сам подскажет, какой тип у переменной. Вот когда видишь странные имена, становится не до типов.

А как у вас устроено код ревью? Я вот в основном в браузере его провожу, читая диффы. И там нормального редактора нет. Поэтому важно, чтобы код читался как есть, в виде текста, в лучшем случае слегка раскрашенного.

Моё правило использования var — если тип очевиден из имени переменной или из инициализирующего значения, то его можно использовать. Если не очевиден, то надо прописывать явный тип. То бишь var x = 1; var s = "hello"; var sb = new StringBuilder(); var appointment = ... (где у appointment тип Appointment). При этом получается примерно 50 на 50 и мне такой результат нравится. По сути цель var в моем коде — убирать дублирование. Нет смысла писать StringBuilder sb = new StringBuilder(), никакой информации это не несёт для читателя. А если несёт, то var не нужен.

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

vsb>Моё правило использования var — если тип очевиден из имени переменной или из инициализирующего значения, то его можно использовать. Если не очевиден, то надо прописывать явный тип. То бишь var x = 1; var s = "hello"; var sb = new StringBuilder(); var appointment = ... (где у appointment тип Appointment). При этом получается примерно 50 на 50 и мне такой результат нравится.

А где примеры неочевидностей, когда явный тип улучшает читаемость?

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>Моё правило использования var — если тип очевиден из имени переменной или из инициализирующего значения, то его можно использовать. Если не очевиден, то надо прописывать явный тип. То бишь var x = 1; var s = "hello"; var sb = new StringBuilder(); var appointment = ... (где у appointment тип Appointment). При этом получается примерно 50 на 50 и мне такой результат нравится.

НС>А где примеры неочевидностей, когда явный тип улучшает читаемость?

        Set<String> sentReferrerIins =
                employeeRepository.queryByIins(organization, referrerIins).stream()
                        .filter(employee -> employee.getStatus() == SENT_TO_API)
                        .map(Employee::getIin)
                        .collect(toSet());

из идентификатора не очевиден тип. Очевидно только то, что это коллекция, но опять же какая коллекция — не понятно, обычно под коллекцией подразумевают List. Что такое iin — может быть это класс такой, без хорошего знания проекта не понять. Если вдумчиво прочитать инициализатор, можно увидеть, что вызывается toSet но это грубо говоря 10 секунд парсинга кода. При этом если тебе конкретно этот код не интересен, а интересен код ниже и тут тебе хочется только увидеть тип этой переменной, то ты эти 10 секунд потратишь отвлекаясь и вытесняя из краткосрочной памяти другие моменты. А с явным типом ты просто игнорируешь инициализирующее значение и сразу видишь тип.

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

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

А зачем тебе для кода ниже знать конкретный тип коллекции? Вот чем конкретно это знание тебе поможет при чтении?

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>А зачем тебе для кода ниже знать конкретный тип коллекции? Вот чем конкретно это знание тебе поможет при чтении?

У Set contains работает за O(1) или O(logN), у List за O(N), то бишь если я увижу строчкой ниже contains в цикле я смогу понять, это потенциальный косяк с O(N^2) или всё хорошо. Также Set убирает дубликаты, List — нет, это тоже может иметь значение для какого-то кода.

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

vsb>У Set contains работает за O(1) или O(logN), у List за O(N)

В этом случае проблема будет именно в том самом коде, который ты читать не хочешь.

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>У Set contains работает за O(1) или O(logN), у List за O(N)

НС>В этом случае проблема будет именно в том самом коде, который ты читать не хочешь.

Проблема будет в коде ниже. К примеру человек что-то снизу дописал и я читаю это изменение в виде diff-а. Для её исправления может понадобиться поменять код выше, согласен, но для того, чтобы в принципе понять, что эта проблема существует, достаточно знать тип, а не код выше.

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

vsb>Проблема будет в коде ниже.

Не, проблема именно в том коде, который не позвал нужный toSet. И в названии переменной, которая не содержит в себе важное семантическое указание.

vsb>:= абсолютно упоротая конструкция. Зачем она нужна в текущем виде — я вообще не понимаю.

Украли из паскаля/дельфи. В известном смысле, ":=" и "=" более явно различаются между собой, нежели "=" и "==". Особенно при быстром просмотре кода и при отсутствующей/неправильной подсветке.

Таки, у меня есть неприличный вопрос для ТС, поркуе ты не используешь Rust?

IMHO, если ты пишешь в команде программистов, которые ничего чуть более сложного, чем Pыthon изучить не хотят — тогда их выбор GoLang. Ну, а если же разработчикам не лень повышать свою квалификацию, то в той же нише больше подходит именно Rust.

• Python — тормозной и примитивный. Осилит каждый (даже если не хочет).
  
• GoLang — быстрый и лишь слегка сложнее, чем Python, уже даже умеет Generic'и. Много рутинного кода, самая дурацкая схема обработки ошибок. Осилит любой желающий.
  
• Rust — быстрый как C++, проще C++, возможностей больше, чем у C++, гораздо удобнее C++. Рутинного кода мало, обработка ошибок через Result<Type,ErrorType> (а-ля std::expected). Осилит любой профессионал. Мутная ситуация с поддержкой долгоживущего кода (edition меняется каждые 3 года и непонятно, что делать со старыми модулями в случае изменения их кода, опыт еще не накоплен).

Таки, шо ты в этот Go полез. Заставили?

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

R>Таки, у меня есть неприличный вопрос для ТС, поркуе ты не используешь Rust?

R>IMHO, если ты пишешь в команде программистов, которые ничего чуть более сложного, чем Pыthon изучить не хотят — тогда их выбор GoLang. Ну, а если же разработчикам не лень повышать свою квалификацию, то в той же нише больше подходит именно Rust.

Ну примерно так, да.

R>

R>
• Python — тормозной и примитивный. Осилит каждый (даже если не хочет).
  R>
• GoLang — быстрый и лишь слегка сложнее, чем Python, уже даже умеет Generic'и. Много рутинного кода, самая дурацкая схема обработки ошибок. Осилит любой желающий.
  R>
• Rust — быстрый как C++, проще C++, возможностей больше, чем у C++, гораздо удобнее C++. Рутинного кода мало, обработка ошибок через Result<Type,ErrorType> (а-ля std::expected). Осилит любой профессионал. Мутная ситуация с поддержкой долгоживущего кода (edition меняется каждые 3 года и непонятно, что делать со старыми модулями в случае изменения их кода, опыт еще не накоплен).
  R>

R>Таки, шо ты в этот Go полез. Заставили?

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

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

vsb>>:= абсолютно упоротая конструкция. Зачем она нужна в текущем виде — я вообще не понимаю.

LK>Украли из паскаля/дельфи. В известном смысле, ":=" и "=" более явно различаются между собой, нежели "=" и "==". Особенно при быстром просмотре кода и при отсутствующей/неправильной подсветке.

Дык там и := есть, и = и ==

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

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

S>>>Точно так же придётся по коду гулять чтобы выяснить тип как ты гулял с именами.

P>>Зачем? Нормальный редактор сам подскажет, какой тип у переменной. Вот когда видишь странные имена, становится не до типов.

vsb>А как у вас устроено код ревью? Я вот в основном в браузере его провожу, читая диффы. И там нормального редактора нет. Поэтому важно, чтобы код читался как есть, в виде текста, в лучшем случае слегка раскрашенного.

vsb>Моё правило использования var — если тип очевиден из имени переменной или из инициализирующего значения, то его можно использовать. Если не очевиден, то надо прописывать явный тип. То бишь var x = 1; var s = "hello"; var sb = new StringBuilder(); var appointment = ... (где у appointment тип Appointment). При этом получается примерно 50 на 50 и мне такой результат нравится. По сути цель var в моем коде — убирать дублирование. Нет смысла писать StringBuilder sb = new StringBuilder(), никакой информации это не несёт для читателя. А если несёт, то var не нужен.

Теперь можно так:

StringBuilder sb = new();

https://riptutorial.com/csharp-9/learn/100003/target-typed-new-expressions

Для более однотипного кода.

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

Ф>>Во-первых, бо ́льшую часть времени оно вообще не нужно: инетесно имя переменной и её значение в текущем месте. Ну вот, например:
S>И как всегда мыслью по древу растекаемся, ага. А вот если бы, а вот рефакторинг, а вот представь...

Бо ́льшая часть разработки ПО — а вот если бы, а вот рефакторинг, а если это... Потому что функционал — %20, а остальное обработка ошибок и нештатных ситуаций.

S>Речь про читабельность и понятность кода.... Скрывать типы в строготипизированном языке под автотип в ущерб читабельности и понятности...

Наоборот: читабельность от этого улучшается, потому что ты не перегружаешь читателя лишней информацией.


S>Давай посмотрим на оригинал (я хз оригинал ли, но явно с этого списано)

Это не оригинал. Оригинал поставляется вместе с RTSS. Если ты его ставил, то находится он здесь:
C:\Program Files (x86)\RivaTuner Statistics Server\SDK\Samples\SharedMemory\RTSSSharedMemorySample\RTSSSharedMemorySampleDlg.cpp

S>>>Да, проще. Не надо угадывать тип переменной, можно просто прочитать его.
НС>>А зачем его угадывать или читать?
S>Возможно ты читаешь код просто так... Ну тебе может и ок. А я в основном дописываю/рефакторю/фикшу баги.

`auto` на возможность это делать влияет примерно никак. На возможность «дописывания» тоже влияет примерно никак.

S>>>Угу, а потом 1.9999883785467 землекопа в отчётах появляются из-за того что int стал float
НС>>У тебя часто так бывало, что int стал float?
S>Ни разу. Потому что строгая типизация. Либо явное приведение.

Итак. Каким образом в отчетах станет «1.9999883785467 землекопа» из-за auto?

Ну и то, что ты путаешь статическую и строгую типизацию, тоже хорошо показывает твое «понимание».