Pull to refresh

Comments 29

UFO just landed and posted this here
А как бы вы перевели заголовок? Заранее спасибо за ответ.
Расчлененка: 26 кусков var и Тайная Комната
Мы решили, что такой громкий и не информативный заголовок лучше не использовать
Пункт 15 какой-то сомнительный, цепочка читается и понимается куда легче, чем разрозненные части.
Автор потом резюмирует
Второй вариант кода выглядит более читабельнее и проще, но первый вариант также имеет право на существование.
Так его резюмирование и сомнительно — для меня второй вариант выглядит менее читабельно. Поспрашивал окружающих, так они со мной согласны.
Ну, можно при чтении кода вскипятить мозги пытаясь понять, что же там на самом деле из функции-то возвращается…
Так тут применяем п.5 и наша SomeAwesomeFunction становится intSomeAwesomeFunction и никаких проблем.
С примитивными типами сработает, а с чем-то кастомным уже нет. Квик-док уже не вызовешь, не почитаешь. Сплошное неудобство.
Придется инфу о возвращаемом типе отражать в имени переменной. Это автор и говорит в статье
… В большинстве случаев это происходит потому, что мы склонны смотреть на тип переменной, как на первичную информацию, а на ее имя, как на вторичную. Хотя должно быть как раз наоборот.
Автор исходит из ошибочного предположения, что информация о типе ограничена его написанием, а это не всегда так. Если String можно безболезненно сократить до str..., то с типом, например, Employee так сделать уже не получится. Сотрудник, это понятно, а конкретно что это значит? Как используется? Какие нюансы? Какой интерфейс реализуется? Контрал+клик, или вызов квикдока на этот и другие вопросы ответит влет, а вот имея перед глазами var employee = getEmployee(accountName) уже ничем не поможет. Придется лезть в тело вызываемой фанкции, смотреть, что конкретно она возвращает, и так далее.

var employee = getEmployee(accountName)
если следовать логике, то тут возвращается объект типа Employe, т.к. эта информация зашита в двух местах: в названии и в геттере

Если нужны нюансы, то автор предлагает максимум информации помещать в название переменной/метода. Это кстати не противоречит рекомендациям из книги Clean Code — давайте именам переменных/класса/метода говорящие имена, чтобы код был самодокументируемым.
если следовать логике, то тут возвращается объект типа Employe, т.к. эта информация зашита в двух местах: в названии и в геттере

Это-то понятно. Не понятно что такое этот Employe, из какого он пакета, что умеет и как с ним жить. Эту информацию невозможно поместить в имя переменной, ее можно получить только из документации. А var лишает нас возможности до нее быстро добраться.
Я думаю, что этот вопрос должен как-то решаться на уровне сред разработки. Ничего не мешает ide автоматом, во время написания кода, уже определять тип переменной employee и давать доступ к соответствующей доке. Поменялся тип, значит и должна автоматом поменяться дока
честно — для меня не понятна претензия.
Я программирую на: JS, TS, GoLang, Python, Ruby, Java (последние 2 давно и мало) — только в TS(опционально) и в GoLang есть статические типы и объявление с типом и без него(на последних Java не работал, где появился var).
Код очень хорошо читается и нет никаких проблем с поиском описания функций. Почему так сильно бомбят с этого в Java мире? вон котлин при своем старте имел это как одна из главных фич и (вроде как) ему за это аплодировали
Для примитивных типов использовать тип var, наверно, особо смысла нет. А в статье это разбирается, как некая возможность, которой можно пользоваться. Из статьи можно сделать вывод, что суть var — это синтаксический сахар над типами, который позволяет писать меньше кода. А это значит, что при использовании var инфу о типе придется переносить в название переменной, что, наверно, не всем будет по душе.

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

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

Это каких? В Котлин вывод типов есть изначально и проблем с этим ни разу не испытывал.

UFO just landed and posted this here
Вроде как этот идентификатор призван упрощать\ускорять, но тут появляется список из рекомендаций типа «как делать не стоит ибо чревато ...». Плюс с этой штукой в эпоху продвинутых IDE приходится нажимать больше клавиш на написание одной строки выражения. Например возьмем две строки:
DocumentationTool dtl = ToolProvider.getSystemDocumentationTool();
var documentationTool = ToolProvider.getSystemDocumentationTool();

При наборе первых двух-трех символов IntelliSense в любой нормальной IDE предложит нужный тип и нам останется нажать только пробел, и следующим пробелом выбрать название переменной которое в 99% будет documentationTool, дальше зная тип технология с большей релевантностью подскажет правую часть выражения.
Для того чтобы получилась вторая строка, нам нужно полностью напечатать var + имя переменной и плюс ко всему IntelliSense будет работать на половину своих возможностей, т.е. когда мы будем печатать правую часть выражения — он просто не даст нам ошибиться в названии класса и метода, т.е. без какой либо фильтрации.
Кстати, такие же проблемы есть в kotlin и swift или может я в чем-то не прав и это действительно нужно?
В нормальной IDE я сперва набираю правую часть с помощью пары символов и IntelliSense, а затем жму ctrl+shift+v, чтоб сгенерировалась левая часть с выбором имени переменной.
тоже подумал о таком юзкейсе, но ни когда так не пробовал делать. Надо попробовать)
в idea Это делается через ctrl + alt + v

Единственное, что полезное вычитал, это замена типа при инициализации конструктором. Тут да, вместо MyAwesomeSuperMegaClassForDoingGreatThings masmcfdgt = new MyAwesomeSuperMegaClassForDoingGreatThings(); превратить в "лаконичное":
var letsDoIt = MyAwesomeSuperMegaClassForDoingGreatThings(); )))

Sign up to leave a comment.

Articles