Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Действительно. Будем считать, что на входе данные соответствуют формату и какой-нибудь тег trash будем приравнивать к тегу trainStation. А кто подаёт на вход данные с заведомо несуществующими тегами, тот сам себе злобный Буратино.
А между тем, значение xpp.getName() может измениться.
Это же метод. Не исключено, что с побочными действиями. Не исключено, что многопоточность.
А, ну да. Тут всё проще. тут типа "оптимизация". Байтоёбство, короче. К тому же бессмысленное и беспощадное с точки зрения оптимизации. Ибо сравнение строк выдаёт false на сравнении первого символа в случае, если они не равны.
А я возьму и соглашусь с каждым словом. Тут нужен либо только свитч (с брейком в каждой ветке), либо только иф-элс (но тогда нужно закешировать вызов метода). Гибрид здесь и вправду не нужен.
Вообще да: если там многопоточность, то метод может вернуть другое значение между 7 и 8 строками. Может получиться ненадежно. Я бы еще проверку сделал чтобы уж точно
if (xpp.getName().equals("airport")) {
if (xpp.getName().equals("airport")) {
if (xpp.getName().equals("airport")) {
if (xpp.getName().equals("airport")) {
parseAirport(xpp, place);
}
}
}
}
}
Если на какую-нибудь букву будет слишком много слов, то алгоритм можно продлить, сделав вложенный свитч по второму символу. И так далее.
Это же метод. Не исключено, что с побочными действиями. Не исключено, что многопоточность.
А, ну да. Тут всё проще. тут типа "оптимизация". Байтоёбство, короче. К тому же бессмысленное и беспощадное с точки зрения оптимизации. Ибо сравнение строк выдаёт false на сравнении первого символа в случае, если они не равны.
Тогда у меня для тебя плохие новости...
З.Ы. Автор просто про break не знал, а вы тут каких-то ужасов навыдумывали 😉
--без нее не работало...