Шедевр кода

[null]

тем кто возмущается отсутствием toUpperCase
хочу заметить, что в коде может быть что-то типа GetCityCodebyCityNameUpper(toUpperCase(string)) написано

[nightmare2]

Линейное программирование использует методы линейной алгебры: матрицы, линейные уравнения там всякие для поиска экстремума.
Отсюда видимо и путаница.

[Prosche]

Нужно еще добавить GetCityCodeByCityNameLower. А вообще Оскара за самый тупой код года я бы не дал, встречал косяки покруче.

Не понял вообще, где тут шедевр. Ну захардкодили коды, бывает... БыдлоКодер видимо не умеет хотя бы ассоциативные массивы использовать...

(Или может получает деньги в зависимости от объема кода. ну так объем есть. КОд работает. Какие собственно претензии??? )

Точно. Вот если бы в коде были кейсы для всех вариантов, мОсква, моСква и тп. Тогда да, немедленно снял бы шляпу.

[StrangerR]

Нужно еще добавить GetCityCodeByCityNameLower. А вообще Оскара за самый тупой код года я бы не дал, встречал косяки покруче.

Не понял вообще, где тут шедевр. Ну захардкодили коды, бывает... БыдлоКодер видимо не умеет хотя бы ассоциативные массивы использовать...

(Или может получает деньги в зависимости от объема кода. ну так объем есть. КОд работает. Какие собственно претензии??? )

Точно. Вот если бы в коде были кейсы для всех вариантов, мОсква, моСква и тп. Тогда да, немедленно снял бы шляпу.

У меня в служебных скриптах такого полным полно (в смысле перебора, а не Москва | мОсква...). Например в привязке к проекту по имени VM тупо стоит куча if на перле. Что мне там, ассоциативный массив писать и шаблоны из него тащить? Надо будет, сделаем, пока не нужно... (НО правда я за объем кода не получаю, просто скрипты категории _раз написать и 100 раз заюзать и все..._)

[VladDod]

Линейное программирование использует методы линейной алгебры: матрицы, линейные уравнения там всякие для поиска экстремума.
Отсюда видимо и путаница.

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

[Prosche]

Нужно еще добавить GetCityCodeByCityNameLower. А вообще Оскара за самый тупой код года я бы не дал, встречал косяки покруче.

Не понял вообще, где тут шедевр. Ну захардкодили коды, бывает... БыдлоКодер видимо не умеет хотя бы ассоциативные массивы использовать...

(Или может получает деньги в зависимости от объема кода. ну так объем есть. КОд работает. Какие собственно претензии??? )

Точно. Вот если бы в коде были кейсы для всех вариантов, мОсква, моСква и тп. Тогда да, немедленно снял бы шляпу.

У меня в служебных скриптах такого полным полно (в смысле перебора, а не Москва | мОсква...). Например в привязке к проекту по имени VM тупо стоит куча if на перле. Что мне там, ассоциативный массив писать и шаблоны из него тащить? Надо будет, сделаем, пока не нужно... (НО правда я за объем кода не получаю, просто скрипты категории _раз написать и 100 раз заюзать и все..._)

Вы позволите я вам как художник художнику...
Не красит вас это признание. Пишите шаблоны, используйте алгоритмы, вы увидите, вам понравится и это ремесленничество уйдет из вас. И код станет короче и красивее без всяких свитчей и ифов. Чесслово. Я не силен в шарпе, но вот пример того же кода, но case insensitive. Разве не коротко и читаемо?

Code: Select all

	static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
				{"МОСКВА","000000010"},
				{"ХИМКИ", "000000193"},
				{"САНКТ-ПЕТЕРБУРГ","000000001"}
			};
	private static string GetCityCodeByCityName(string name)
	{
		try { return v[name.ToUpper()]; }
		catch { return "000000000"; }
	}

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

Где грохнется вышепреведенный код будучи инициализированным
static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
{"МОСКВА","000000010"},
{"ХИМКИ", "000000193"},
{"МОСКВА","000000020"},
{"САНКТ-ПЕТЕРБУРГ","000000001"}

[tessob]

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

[Dmitry67]

Еще помню, бывает ВЫПУКЛОЕ программирование
И главное, никакого отношения это к современному программированию не имеет

[Prosche]

Где грохнется вышепреведенный код будучи инициализированным
static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
{"МОСКВА","000000010"},
{"ХИМКИ", "000000193"},
{"МОСКВА","000000020"},
{"САНКТ-ПЕТЕРБУРГ","000000001"}

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

[Palych]

Разрабы ведь запусают то, что пишут, хоть раз.

Это ещё зачем?
А вдруг не заработает?...

[geek7]

Где грохнется вышепреведенный код будучи инициализированным
static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
{"МОСКВА","000000010"},
{"ХИМКИ", "000000193"},
{"МОСКВА","000000020"},
{"САНКТ-ПЕТЕРБУРГ","000000001"}

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

ха. во первых не всегда. во 2-х запросто тесты могут не покрывать.
кстати, помнится, в жабе ексепшен в статической инициализации (например создании объекта для статического поля) приводил к заявлению "класс не найден", что приводило в недоумении немало индусов... типа вот же он - класс в пути всё пучком, даже какой-то код инициализации может успеть выполнится и вдруг NoClassDefFoundError. Отсюда у меня некоторая нелюбовь к сколько-нибудь сложным действиям в процессе загрузки класса - обязательно кто-то дополнит и потом не сможет разобратся куда исчез класс который только-что был.
дот нет тут что-то менее лукавое выдаёт?

[geek7]

Code: Select all

	static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
				{"МОСКВА","000000010"},
				{"ХИМКИ", "000000193"},
				{"САНКТ-ПЕТЕРБУРГ","000000001"}
			};
	private static string GetCityCodeByCityName(string name)
	{
		try { return v[name.ToUpper()]; }
		catch { return "000000000"; }
	}

я в сишарпном синтаксисе не копенгаген, но если кто-то v = null; сделает, то GetCityCodeByCityName на все города будет выдавать "000000000" (как и на аргумент null )?
извиняюсь за глупый вопрос

[Prosche]

ха. во первых не всегда. во 2-х запросто тесты могут не покрывать.
кстати, помнится, в жабе ексепшен в статической инициализации (например создании объекта для статического поля) приводил к заявлению "класс не найден", что приводило в недоумении немало индусов... типа вот же он - класс в пути всё пучком, даже какой-то код инициализации может успеть выполнится и вдруг NoClassDefFoundError. Отсюда у меня некоторая нелюбовь к сколько-нибудь сложным действиям в процессе загрузки класса - обязательно кто-то дополнит и потом не сможет разобратся куда исчез класс который только-что был.
дот нет тут что-то менее лукавое выдаёт?

Ну вы сравнили тоже... Прекрасный язык и жабу!
Специально для вас запустил:

[System.ArgumentException: An item with the same key has already been added.]
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Program..cctor() :line 6

Думаю даже индусы бы дотумкали

[Prosche]

Code: Select all

	static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
				{"МОСКВА","000000010"},
				{"ХИМКИ", "000000193"},
				{"САНКТ-ПЕТЕРБУРГ","000000001"}
			};
	private static string GetCityCodeByCityName(string name)
	{
		try { return v[name.ToUpper()]; }
		catch { return "000000000"; }
	}

я в сишарпном синтаксисе не копенгаген, но если кто-то v = null; сделает, то GetCityCodeByCityName на все города будет выдавать "000000000" (как и на аргумент null )?
извиняюсь за глупый вопрос

Будет, что логично, нет словаря, нет и результата, но v приватный (по умолчанию в шарпе) член класса (я уж класс в примере не стал делать, но он есть ), т.е. изменить снаружи класса его нельзя. Можно конечно изнутри. Если это проблема, можно сделать интерфейс с гетером и обращаться через него, но это уже немного паранойя, потому что с таким же успехом враг может и просто саму функцию заменить:
private static string GetCityCodeByCityName(string name)
{
return "000000000";
}

[geek7]

Code: Select all

	static IReadOnlyDictionary<string,string> v = new Dictionary<string, string>() {
				{"МОСКВА","000000010"},
				{"ХИМКИ", "000000193"},
				{"САНКТ-ПЕТЕРБУРГ","000000001"}
			};
	private static string GetCityCodeByCityName(string name)
	{
		try { return v[name.ToUpper()]; }
		catch { return "000000000"; }
	}

я в сишарпном синтаксисе не копенгаген, но если кто-то v = null; сделает, то GetCityCodeByCityName на все города будет выдавать "000000000" (как и на аргумент null )?
извиняюсь за глупый вопрос

Будет, что логично, нет словаря, нет и результата, но v приватный (по умолчанию в шарпе) член класса, т.е. изменить снаружи класса его нельзя. Можно конечно изнутри. Если это проблема, можно сделать интерфейс с гетером и обращаться через него, но это уже немного паранойя, потому что с таким же успехом враг может и просто саму функцию заменить:
private static string GetCityCodeByCityName(string name)
{
return "000000000";
}

ну тут злой умысел будет налицо.. а вот если он таки сподобится загрузить список из какой-то базы/файла итд и катапейстнет свой IReadOnlyDictionary loadCityCodeByCityName() из Вашего примера string GetCityCodeByCityName() заменив catch { return "000000000"; } на catch { return null; } а к базе законектится в продакшене не получится...
то имеем "всё работает в деве, в продакшене все города возвращают "000000000"" и 2 проглоченные эксепшены - одна индусом о коннекте к базе, другая Вами о налпойнтере....как-то так
короче: булет-пруфт код тоже может оказатся неполезным

PS Я правильно понимаю, что в Вашем варианте Dictionary вернёт null на город "зажопинск", а Димин пример "000000000" ? а если у них юнит-теста на несуществующий город нет?

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

[Prosche]

ну тут злой умысел будет налицо.. а вот если он таки сподобится загрузить список из какой-то базы/файла итд и катапейстнет свой IReadOnlyDictionary loadCityCodeByCityName() из Вашего примера string GetCityCodeByCityName() заменив catch { return "000000000"; } на catch { return null; } а к базе законектится в продакшене не получится...
то имеем "всё работает в деве, в продакшене все города возвращают "000000000"" и 2 проглоченные эксепшены - одна индусом о коннекте к базе, другая Вами о налпойнтере....как-то так
короче: булет-пруфт код тоже может оказатся неполезным

PS Я правильно понимаю, что в Вашем варианте Dictionary вернёт null на город "зажопинск", а Димин пример "000000000" ? а если у них юнит-теста на несуществующий город нет?

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

Да, такое же ощущение
В своем примере я не менял не входящие не выходящие значения, а оставил как у Димы, на входе город, на выходе код или "0000000" если не найден. По уму я бы конечно исходил из задачи, если есть шанс, что словарь не захардкожен, а грузится и может быть поврежден, сделал бы проверку, возможно в функции, возможно в конструкторе, исходя из логики загрузки. Если не найденный город плохо, то вместо return "0000000" бросал бы эксепшн и т.д. Идея была показать, что решение со словарем ничуть не длиннее, не сложнее, не... в общем лучше всяких ифов и свитчей:)

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

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

[Prosche]

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

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

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

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

[Prosche]

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

[Pantigalt]

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

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

То что можно использовать исключения никто не спорит. Но нужно ли?
Почему вы думаете что область применения исключений в С++ и C# должно отличаться?
Одной из причин появления исключений в C++ изначально являлась генерация ошибки в конструкторе по разным причинам.

В примере вполне можно без исключений обоитись проверяя наличие значения в словаре и проверяяя ключ на null.

[geek7]

Идея была показать, что решение со словарем ничуть не длиннее, не сложнее, не... в общем лучше всяких ифов и свитчей:)

Т.е. поскольку место капитана уже занято
подались в лейтенанты

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

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

C трудом представляю как там вообще можно пользоваться шарпом, где одна среда исполнения весит немеряно.
Обычно при программировании встроенного железа исключения вообще отрубают нафиг на этапе компиляции.

[AndreyT]

...фактически исключение в плюсах это аппликация валиться и перед смертью мы пытаемся чтото спасти или зафиксировать в журнале,...

Нет, ни в коем случае. В плюсах исключения - обработка нештатных ситуаций, т.е. ошибок, но совсем не обязательно связанных с "аппликация валиться и перед смертью". Вся философия исключений в С++ построена вокруг идеи того, что исключения являются recoverable. "Перед смертью" - это скорее подыерархия logical errors. Когда же речь идет о подыерархии runtime errors, никакого "перед смертью" не подразумевается.

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