разработчики не понимают, что самая лучшая подача была в гугл картах — там просто показывали последнее местоположение автобуса, и время, когда оно было получено... на основе чего человек сам мог понять, где сейчас находится автобус
На удивление получившийся код читается намного хуже, чем исходный, 64 строки в одном методе, метод выполняет как минимум три функции, миллион локальных переменных наподобие листов или итераторов(хотя нам прекрасно жилось без итераторов с c-like фором или с нефайнал переменными вместо листов размером 1, что не является назначением листа), наряду с result, от которого ты не знаешь, чего ожидать в конце метода(или в любой его части ввиду размера самого метода), ещё большей вложенностью if-else, логикой в конструкторе, а не в фабричном методе, который бы делегировал обязанности нужным классам, и разработчику бы вообще не приходилось думать о внутренней реализации.
компилятор не знает об изменениях, сделанных другим потоком. как минимум потому, что они могут случиться в любой момент времени, а не в определённый, как это происходит в текущем потоке.
HashMap<String, List<String>> temporaryMap = new HashMap<>();
var temporaryMap1 = new HashMap<String, List<String>>();
MyObject object = new MyObject();
var object1 = new MyObject();
MethodHandle methodHandle = parseMethodHandle(sourceOfMethodHandle);
var methodHandle1 = parseMethodHandle(sourceOfMethodHandle);
Ну и чем здесь var хуже явного указания типа? Это особенно удобно при очевидном длинном типе.
разработчики не понимают, что самая лучшая подача была в гугл картах — там просто показывали последнее местоположение автобуса, и время, когда оно было получено... на основе чего человек сам мог понять, где сейчас находится автобус
что за анекдот?
SmallTalk
На удивление получившийся код читается намного хуже, чем исходный, 64 строки в одном методе, метод выполняет как минимум три функции, миллион локальных переменных наподобие листов или итераторов(хотя нам прекрасно жилось без итераторов с c-like фором или с нефайнал переменными вместо листов размером 1, что не является назначением листа), наряду с result, от которого ты не знаешь, чего ожидать в конце метода(или в любой его части ввиду размера самого метода), ещё большей вложенностью if-else, логикой в конструкторе, а не в фабричном методе, который бы делегировал обязанности нужным классам, и разработчику бы вообще не приходилось думать о внутренней реализации.
компилятор не знает об изменениях, сделанных другим потоком. как минимум потому, что они могут случиться в любой момент времени, а не в определённый, как это происходит в текущем потоке.
Ну и чем здесь var хуже явного указания типа? Это особенно удобно при очевидном длинном типе.
Если вы используете var и делаете ваш код нечитаемым -- не делайте так. var нужно использовать там, где тип очевиден.