Комментарии 29
НЛО прилетело и опубликовало эту надпись здесь
Пункт 15 какой-то сомнительный, цепочка читается и понимается куда легче, чем разрозненные части.
В чём сакральный смысл замены int на var?
Модно, стильно, молодёжно!
Ну, можно при чтении кода вскипятить мозги пытаясь понять, что же там на самом деле из функции-то возвращается…
Так тут применяем п.5 и наша SomeAwesomeFunction становится intSomeAwesomeFunction и никаких проблем.
Придется инфу о возвращаемом типе отражать в имени переменной. Это автор и говорит в статье
… В большинстве случаев это происходит потому, что мы склонны смотреть на тип переменной, как на первичную информацию, а на ее имя, как на вторичную. Хотя должно быть как раз наоборот.
Автор исходит из ошибочного предположения, что информация о типе ограничена его написанием, а это не всегда так. Если String можно безболезненно сократить до str..., то с типом, например, Employee так сделать уже не получится. Сотрудник, это понятно, а конкретно что это значит? Как используется? Какие нюансы? Какой интерфейс реализуется? Контрал+клик, или вызов квикдока на этот и другие вопросы ответит влет, а вот имея перед глазами var employee = getEmployee(accountName) уже ничем не поможет. Придется лезть в тело вызываемой фанкции, смотреть, что конкретно она возвращает, и так далее.
var employee = getEmployee(accountName)
если следовать логике, то тут возвращается объект типа Employe, т.к. эта информация зашита в двух местах: в названии и в геттере
Если нужны нюансы, то автор предлагает максимум информации помещать в название переменной/метода. Это кстати не противоречит рекомендациям из книги Clean Code — давайте именам переменных/класса/метода говорящие имена, чтобы код был самодокументируемым.
если следовать логике, то тут возвращается объект типа Employe, т.к. эта информация зашита в двух местах: в названии и в геттере
Если нужны нюансы, то автор предлагает максимум информации помещать в название переменной/метода. Это кстати не противоречит рекомендациям из книги Clean Code — давайте именам переменных/класса/метода говорящие имена, чтобы код был самодокументируемым.
если следовать логике, то тут возвращается объект типа Employe, т.к. эта информация зашита в двух местах: в названии и в геттере
Это-то понятно. Не понятно что такое этот Employe, из какого он пакета, что умеет и как с ним жить. Эту информацию невозможно поместить в имя переменной, ее можно получить только из документации. А var лишает нас возможности до нее быстро добраться.
честно — для меня не понятна претензия.
Я программирую на: JS, TS, GoLang, Python, Ruby, Java (последние 2 давно и мало) — только в TS(опционально) и в GoLang есть статические типы и объявление с типом и без него(на последних Java не работал, где появился var).
Код очень хорошо читается и нет никаких проблем с поиском описания функций. Почему так сильно бомбят с этого в Java мире? вон котлин при своем старте имел это как одна из главных фич и (вроде как) ему за это аплодировали
Я программирую на: JS, TS, GoLang, Python, Ruby, Java (последние 2 давно и мало) — только в TS(опционально) и в GoLang есть статические типы и объявление с типом и без него(на последних Java не работал, где появился var).
Код очень хорошо читается и нет никаких проблем с поиском описания функций. Почему так сильно бомбят с этого в Java мире? вон котлин при своем старте имел это как одна из главных фич и (вроде как) ему за это аплодировали
Для примитивных типов использовать тип var, наверно, особо смысла нет. А в статье это разбирается, как некая возможность, которой можно пользоваться. Из статьи можно сделать вывод, что суть var — это синтаксический сахар над типами, который позволяет писать меньше кода. А это значит, что при использовании var инфу о типе придется переносить в название переменной, что, наверно, не всем будет по душе.
Единообразие кода, привыкаешь везде использовать var, в том числе для примитивных типов.
Пункт 0: не используйте var вообще…
Вроде как этот идентификатор призван упрощать\ускорять, но тут появляется список из рекомендаций типа «как делать не стоит ибо чревато ...». Плюс с этой штукой в эпоху продвинутых IDE приходится нажимать больше клавиш на написание одной строки выражения. Например возьмем две строки:
При наборе первых двух-трех символов IntelliSense в любой нормальной IDE предложит нужный тип и нам останется нажать только пробел, и следующим пробелом выбрать название переменной которое в 99% будет documentationTool, дальше зная тип технология с большей релевантностью подскажет правую часть выражения.
Для того чтобы получилась вторая строка, нам нужно полностью напечатать var + имя переменной и плюс ко всему IntelliSense будет работать на половину своих возможностей, т.е. когда мы будем печатать правую часть выражения — он просто не даст нам ошибиться в названии класса и метода, т.е. без какой либо фильтрации.
Кстати, такие же проблемы есть в kotlin и swift или может я в чем-то не прав и это действительно нужно?
DocumentationTool dtl = ToolProvider.getSystemDocumentationTool();
var documentationTool = ToolProvider.getSystemDocumentationTool();
При наборе первых двух-трех символов IntelliSense в любой нормальной IDE предложит нужный тип и нам останется нажать только пробел, и следующим пробелом выбрать название переменной которое в 99% будет documentationTool, дальше зная тип технология с большей релевантностью подскажет правую часть выражения.
Для того чтобы получилась вторая строка, нам нужно полностью напечатать var + имя переменной и плюс ко всему IntelliSense будет работать на половину своих возможностей, т.е. когда мы будем печатать правую часть выражения — он просто не даст нам ошибиться в названии класса и метода, т.е. без какой либо фильтрации.
Кстати, такие же проблемы есть в kotlin и swift или может я в чем-то не прав и это действительно нужно?
Единственное, что полезное вычитал, это замена типа при инициализации конструктором. Тут да, вместо MyAwesomeSuperMegaClassForDoingGreatThings masmcfdgt = new MyAwesomeSuperMegaClassForDoingGreatThings(); превратить в "лаконичное":
var letsDoIt = MyAwesomeSuperMegaClassForDoingGreatThings(); )))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
26 рекомендаций по использованию типа var в Java