Шедевр кода

[OtherSide]

не гони, я ничего абсолютно не тер. Следи за руками, не гоняй порожняки!

значит приглючилось

[Dmitry67]

Красные подчеркивания мне прислали
Они там видимо что-то обсуждали

[Мальчик-Одуванчик]

А если писать для какого-нибудь микропроцессора с ограниченным набором памяти - то именно через оператор ветвления и придется корячиться. Можно так-же предположить, что переферийное оборудование выдает название города только большими буквами.
В этом случае исправленный пример выглядит вполне корректным так как предполагает что входной параметр заведомо в верхнем регистре.
Хотя сам скрин кода, показанного в студии делает сомнительным эти рассуждения для конкретного кода.
Другой вариант - это перенос очень старого кода, где ранее город задавался только большими буквами, а при переносе это требование было аннулировано. Тогда попытки исправления кода без добавления новых библиотек выглядят вполне логичными.

[Мальчик-Одуванчик]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

Да нифига. Из показанного куска кода вовсе не следует что город вводится пользователем. Это может быть, к примеру, радиограмма.
Поэтому можно лишь предположить что название города поступает всегда в верхнем регистре или переводится в оный сразу на этапе получения.

[Prosche]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

Да нифига. Из показанного куска кода вовсе не следует что город вводится пользователем. Это может быть, к примеру, радиограмма.
Поэтому можно лишь предположить что название города поступает всегда в верхнем регистре или переводится в оный сразу на этапе получения.

Не надо ничего предполагать, надо писать код, который будет работать всегда и везде.

[Мальчик-Одуванчик]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

Да нифига. Из показанного куска кода вовсе не следует что город вводится пользователем. Это может быть, к примеру, радиограмма.
Поэтому можно лишь предположить что название города поступает всегда в верхнем регистре или переводится в оный сразу на этапе получения.

Не надо ничего предполагать, надо писать код, который будет работать всегда и везде.

Если по условиям задачи строка поступает в верхнем регистре, то дополнительное её перекодирование снова в верхний регистр выглядит еще большей глупостью.

[Prosche]

По условиям задачи... Смею предположить, что вам ближе академическая деятельность.

[AndreyT]

Придирка совершенно левая. Придраться можно, но это явный "nothing to write home about". Какие-нибудь забубенные "практики" данной предметной области возможно даже веско заметят, что вместо того, чтобы завязываться на правильность конвертации uppercase-lowercase для кириллических символов, лучше просто явно рассмотреть возможные случаи по отдельности. И, вполне возможно, они даже будут правы.

Зачем писали две отдельные функции - не ясно, ибо это maintenance nightmare. Но не более того...

[Pantigalt]

лучше просто явно рассмотреть возможные случаи по отдельности. И, вполне возможно, они даже будут правы.

Зачем писали две отдельные функции - не ясно, ибо это maintenance nightmare. Но не более того...

A чем именно лучше? Вы не доверяете функциям конвертации на кириллице?
То что внизу конечно не видно но можно предположить что там тоже кириллица.
Если бы хорошие кодеры предполагали ваш вариант "рассмотреть возможные случаи по отдельности" то написали бы поясняющий комментарий.

[Dmitry67]

Наиболее странно здесь что делается reverse lookup - не из id в name, а наоборот. В хорошо спроектированной системе такого не должно.быть, равно как и hardcoded list.

Однако можно с большой вероятностью предложить, зачем такое нужно: рендерят страницу, на ней оказывается название города форматированное разным образом, а id нет. А оно нужно для обращения к базе. Его и находят обратными ходом

В любом случае приговор один, расстрел.

[AndreyT]

Наиболее странно здесь что делается reverse lookup - не из id в name, а наоборот. В хорошо спроектированной системе такого не должно.быть,

Мимо кассы. Понятно, что lookup из id в name у них, без сомнения, есть - вы его просто не показали. А причин для реализации обратного lookup из name в id могут быть миллионы разных. Интерфейсные, например.

равно как и hardcoded list.

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

Однако можно с большой вероятностью предложить, зачем такое нужно: рендерят страницу, на ней оказывается название города форматированное разным образом, а id нет. А оно нужно для обращения к базе. Его и находят обратными ходом

С еще большей вероятностью некие данные идут из какой-то third party системы, с которой нет договоренности о согласованных стандартизованных id населенных пунктов (да и не нужно - это было бы криво), но зато есть стандартизованные текстовые названия по какому-нибудь ГОСТу (как и должно быть).

В любом случае приговор один, расстрел.

Высосано из пальца.

[Dmitry67]

Нет, это веб сайт. Они сами там властны делать что хотят. А сделали это

[Pantigalt]

Мимо кассы. Понятно, что lookup из id в name у них, без сомнения, есть - вы его просто не показали. А причин для реализации обратного lookup из name в id могут быть миллионы разных. Интерфейсные, например.

Можно предположить что угодно.
Но согласно бритве Оккама самое простое объяснение порой самое лучшее.
Если бы что то подразумевали написали бы комментарии хотя бы.

[helg]

У Microsoft постоянно какие-то проблемы с русским. Системная функция перевода регистра у них вечно зависела от каких-то магических системных параметров типа кодовой страницы или unicode супротив зоопарка multibyte. Причём эти установки могли различаться не только между машиной разработчика и разными серверами по дороге до боевого, но даже для разных приложений/процессов внутри одной Windows.

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

Нет уж. В такой зыби лучше писать понадёжнее. Пусть это и выглядит смешным на первый взгляд.

[alex_127]

зоопарк с collation, encoding, coordinate systems (аnd also time zones which change 10 time per year) гарантирует что пришельцы никогда не сумеют попасть в то место и время чтобы поработить землю одним щелчком.

[geek7]

Концентрация идиотов в индустрии ассимптотически стремится к их концентрации в общем населении. В эпоху зеленых телевизоров
количество приличных людей среди пишущих код было значительно больше. Сейчас же столько пены. Вон ммодел - двух слов связать не
может, а все туда же - код писать.

о чем вы говорите, наоброт требования повышаются, в 80х это был фан и романтика, никакой культуры кодирования не было вообще.
Кстати в данном примере ошибка не только в том, что не использовался ToUpperCase(), там вместо кейсов можно было проинициализировать Dictionary readonly, он еще и быстрее работал бы.

Dictionary readonly это сишарповский мап? Я думаю про GetCityCodeByCityNameLower это была шьютка юмора, а Дима ожидал возмушения варварским хардкодом.
По части "требования повышаются" ... во первых это не противоречит утверждения sfbaguy1 - и требования меняются и количество людей в профессии сильно увеличилось.
я бы сказал, сильно увеличивается %% прикладного ПО в том числе очень большие и сложные проекты.
Соответственно кроме оптимальности кода становятся более важными моменты его доступности для коллег, поддержка, расширяемость итд. С другой стороны инструменты сильно развились и позволяют людям с гораздо более низкой квалификацией писать сильно более сложные вещи.
IMO это как раз большой прогресс, что даже вчерашний парихмахер с гуманитарным складом ума таки может сделать что-то полезное.

[geek7]

Ну да, не было культуры кодирования. До 80х был создан весь фундамент - Кнут, Вирт, структурное программирование, Ахо-Хопкрофт-Ульман, Unix.
Да и софт, который тогда создавался, был серьезней, чем сейчас. Индусская копипаста не прокатила бы. Веба не было как класса.
Программисты были суровые бородатые белые мужики. Эдакие джедаи, не то что щас - всякое чмо и быдло.

джедаи и сейчас есть, более того простора помахать световыми мечами куда поболе. опять же в фундамент Unix я не заглядывал, но некоторые кирпичики той-же жабы ещё из того гхм..на были сляпаны, подозреваю что и в nix-сах копипаста прокатывала там-сям и даже мигрировала между операционками.

[geek7]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

возможно toUpperCase() делается на стороне клиента и в серверном коде нафиг не нужна. типа по спецификации входящие данные уже должны быть в верхнем регистре и нефиг городить отсебятину, но наличие первой функции заставляет сомневатся в этой теории

[XAOC]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

возможно toUpperCase() делается на стороне клиента и в серверном коде нафиг не нужна. типа по спецификации входящие данные уже должны быть в верхнем регистре и нефиг городить отсебятину, но наличие первой функции заставляет сомневатся в этой теории

Вон из профессии за такое


Sent from my iPhone using Tapatalk

[geek7]

в данном случае не использование toUpperCase() - это просто неграмотность, а не оптимизация. К тому же, простая ашипка юзера, ввод типа "МОСКВа" просто не будет обработан.

возможно toUpperCase() делается на стороне клиента и в серверном коде нафиг не нужна. типа по спецификации входящие данные уже должны быть в верхнем регистре и нефиг городить отсебятину, но наличие первой функции заставляет сомневатся в этой теории

Вон из профессии за такое

судя по тому, что диме прислали уже с подчёркиваниями, даже в этой конторе уже консенсус по данному вопросу... но прикольно погадать какими соображениями мог руководствоватся афтар. например идея с проблемами кодировок в винде мне показалась забавной. насчёт оптимизации скорости хеш vs ветвление - тоже прикольно.

[Dmitry67]

Концентрация идиотов в индустрии ассимптотически стремится к их концентрации в общем населении. В эпоху зеленых телевизоров
количество приличных людей среди пишущих код было значительно больше. Сейчас же столько пены. Вон ммодел - двух слов связать не
может, а все туда же - код писать.

о чем вы говорите, наоброт требования повышаются, в 80х это был фан и романтика, никакой культуры кодирования не было вообще.
Кстати в данном примере ошибка не только в том, что не использовался ToUpperCase(), там вместо кейсов можно было проинициализировать Dictionary readonly, он еще и быстрее работал бы.

Dictionary readonly это сишарповский мап? Я думаю про GetCityCodeByCityNameLower это была шьютка юмора, а Дима ожидал возмушения варварским хардкодом.
По части "требования повышаются" ... во первых это не противоречит утверждения sfbaguy1 - и требования меняются и количество людей в профессии сильно увеличилось.
я бы сказал, сильно увеличивается %% прикладного ПО в том числе очень большие и сложные проекты.
Соответственно кроме оптимальности кода становятся более важными моменты его доступности для коллег, поддержка, расширяемость итд. С другой стороны инструменты сильно развились и позволяют людям с гораздо более низкой квалификацией писать сильно более сложные вещи.
IMO это как раз большой прогресс, что даже вчерашний парихмахер с гуманитарным складом ума таки может сделать что-то полезное.

Про порог вхождения я согласен. С одной стороны, я против быдлокода. С другой стороны, код, написанный иными гуру... Помните пример когда hello world пишется на несколько страниц с классами там presenter, observer, и еще чего то...

Как приятно вернуться к процедурному SQL из мира, где реальность мелко настругана на десятки мелких однострочных классов, абстрактных до такой степени что не видишь никакой связи с реальностью, всякие фабрики фабрик фабрик...

[Dmitry67]

Кстати, вот тут:

https://m.geektimes.ru/post/297073/

быдлопрограммеры делают каминг аут

[OtherSide]

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

Нет такого, это как раз 20 лет назад можно было прийти в индустрию с улицы, сейчас - увы

[Dmitry67]

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

Нет такого, это как раз 20 лет назад можно было прийти в индустрию с улицы, сейчас - увы

А после выпаса коров в Индии в индустрию типа не придти?

P.S. ИНДУСтрия... Совпадение? Не думаю (С)

[geek7]

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

Нет такого, это как раз 20 лет назад можно было прийти в индустрию с улицы, сейчас - увы

Я это переодически слышу.. а потом очередной подьём и те кто не воротят нос от маленьких по мнению "дедов" зряплат итд таки находят способы и резоны войти. уж в какую профессию с улицы войти можно то это в IT .. в дворники может и попроще, но не факт