англо язычных, почему то, фиджета, резульатом. + Стилистические, пунктуационные ошибки + Никуда не годный язык статьи. Рускоязычные статьи по виджетам и тутесть:
var xDoc = new XDocument(
new XElement("ya_lbs_request",
new XElement("common",
new XElement("version", YaLocator.Version),
new XElement("api_key", YaLocator.ApiKey)),
new XElement("gsm_cells",
new XElement("countrycode", YaLocator.CountryCode),
new XElement("operatorid", YaLocator.OperatorId),
new XElement("cellid", YaLocator.CellId),
new XElement("lac", YaLocator.Lac),
new XElement("signal_strength", YaLocator.SignalStrengthGsm),
new XElement("age", YaLocator.Age)),
new XElement("wifi_networks",
new XElement("network",
new XElement("mac", YaLocator.Mac),
new XElement("signal_strength", YaLocator.SignalStrengthWiFi))),
new XElement("ip",
new XElement("address_v4", YaLocator.IP))));
var sentData = System.Text.Encoding.UTF8.GetBytes(string.Format("xml={0}", xDoc.ToString()));
req.ContentLength = sentData.Length;
using (var sendStream = req.GetRequestStream())
{
sendStream.Write(sentData, 0, sentData.Length);
}
var response = (HttpWebResponse)req.GetResponse();
var buf = new byte[response.ContentLength];
Да, и меня смущает всё время это «переведен вручную». Но зачастую там откровенные моменты есть, которые… ну никак не мог бы допустить человек с минимальным знанием английского.
Едем дальше:
1) «Не рекомендуется» — это да. Но обратите внимание, как осторожны здесь авторы. Они говорят «Как правило, не рекомендуется» (<=> «Обычно, не рекомендуется»). Это значит, что есть исключения, и именно в конкретных исключительных ситуациях (блок switch, выход из вложенных циклов) goto оправдан и является одним из верных решений.
2) «Удобен в switch» — удобен и в написании (не нужно объявлять меток) и в использовании, но только в ситуациях, когда он там требуется.
3) "… в частности, чтобы проваливаться сквозь метки case" — «разве хорошо проваливаться сквозь метки только потому, что в С/С++ это было, и мы привыкли?» — именно поэтому в C# теперь нельзя проваливаться сквозь case — разработчики языка пытались максимально уменьшить число ошибок, допускаемых программистом («после case cтавь break»), но при этом сохранить гибкость С++ («юзай лучше goto, когда надо повторно использовать код внутри switch и выделять для этого отдельную функцию малоприемлемо»).
4) «Код должен быть скучной инструкцией, а не детективом» — если имеется ввиду, что goto «перебрасывает» через код, то вызов функции — это тоже «скачёк» к другому участку, в конце while, for тоже скачёк к началу цикла.
… У меня вёл преподаватель, который категорически запрещал goto, break (кроме как в switch), continue и несколько return-ов. Просто сказал бы «переписывай», если бы я заюзал «сами знаете что». Попытавшись с ним поспорить однажды нарвался на некоторую грубость и нежелание слушать. Не то, чтобы «запретный плод сладок», но в процессе своего самообразования я понимал, что это скорее предвзятость и «старая школа», а новая учит использовать весь доступный в языке инструментарий (иначе зачем его туда ввели разработчики языка — думаю первые, кто знает, что делают), но с умом.
Это автоматический перевод на русский. Примеры, как можно понять, демонстративные — демонстрируют, какой синтаксис нужно использовать для goto внутри того же switch — и я не вижу смысла где-то зараннее объявлять числа, чтобы они перестали быть волшебными, а пример от этого стал длиннее.
Может, авторитетным для вам окажется мнение 9 специалистов (Симон Робинсон, Олли Корнес...), написавших «C# для профессионалов»: «Как правило, не рекомендуется использовать оператор goto. Вообще говоря, его применение противоречит объектно-ориентированному стилю программирования. Однако в одном случае этот оператор очень удобен — в случае переходов между метками в операторе switch, в частности потому, что оператор switch в C# не позволяет „проваливаться“ сквозь метки case.»
Да в C++ механизм обработки исключений тоже не идеален. Нет блока try/catch/finally — попробуй сделай нормально финализацию. А блок try/catch не перехватывает Win32-исключений (например, ошибка деления на ноль). В свою очерень, SEX-блок __try/__finally может не перехватывать исключения C++.
Большинство выбирает путь наименьшего сопротивления. Если бы да кабы тут не покатит. Это реальность, она уже сложилась.
Однако, если гипотетически мои друзья выбрали бы заведомо более сложный путь — я бы недоумевал. Скорее всего, в предположении логичности их действий, они увидели бы в этом пути определённую выгодную сторону, которую я бы также попытался узнать и, возможно, перешёл бы на их способ/метод. В противном случае, если бы я не увидел долгосрочной выгоды в их решении, я бы посчитал их решение нелогичным, и выбрал бы путь, который, как вы говорите, помог бы мне «стать на голову выше их по скилам». Но тут надо заметить — моё стремление не в «стать на голову выше», а в «стать хорошим и востребованным специалистом», чтобы «рубить бабло» и, в том числе, иметь возможность покупать лицензионный софт.
У меня нет денег на лицензионный софт (по крайней мере, пока точно нет). Мои друзья «повышают свою стоимость на рынке труда» наращивая скилы за счёт нелицензионного софта/книг. Мне было бы тяжело составить им конкуренцию, если бы я не поступал также.
Плохо.
Меня переучит только необходимое количество кактусов.
p. s. Всем интересующимся — рабочий пример использования Яндекс.Локатор на C# (только подставьте свой ApiKey, если нету — можно получить здесь):
Едем дальше:
1) «Не рекомендуется» — это да. Но обратите внимание, как осторожны здесь авторы. Они говорят «Как правило, не рекомендуется» (<=> «Обычно, не рекомендуется»). Это значит, что есть исключения, и именно в конкретных исключительных ситуациях (блок switch, выход из вложенных циклов) goto оправдан и является одним из верных решений.
2) «Удобен в switch» — удобен и в написании (не нужно объявлять меток) и в использовании, но только в ситуациях, когда он там требуется.
3) "… в частности, чтобы проваливаться сквозь метки case" — «разве хорошо проваливаться сквозь метки только потому, что в С/С++ это было, и мы привыкли?» — именно поэтому в C# теперь нельзя проваливаться сквозь case — разработчики языка пытались максимально уменьшить число ошибок, допускаемых программистом («после case cтавь break»), но при этом сохранить гибкость С++ («юзай лучше goto, когда надо повторно использовать код внутри switch и выделять для этого отдельную функцию малоприемлемо»).
4) «Код должен быть скучной инструкцией, а не детективом» — если имеется ввиду, что goto «перебрасывает» через код, то вызов функции — это тоже «скачёк» к другому участку, в конце while, for тоже скачёк к началу цикла.
… У меня вёл преподаватель, который категорически запрещал goto, break (кроме как в switch), continue и несколько return-ов. Просто сказал бы «переписывай», если бы я заюзал «сами знаете что». Попытавшись с ним поспорить однажды нарвался на некоторую грубость и нежелание слушать. Не то, чтобы «запретный плод сладок», но в процессе своего самообразования я понимал, что это скорее предвзятость и «старая школа», а новая учит использовать весь доступный в языке инструментарий (иначе зачем его туда ввели разработчики языка — думаю первые, кто знает, что делают), но с умом.
Может, авторитетным для вам окажется мнение 9 специалистов (Симон Робинсон, Олли Корнес...), написавших «C# для профессионалов»: «Как правило, не рекомендуется использовать оператор goto. Вообще говоря, его применение противоречит объектно-ориентированному стилю программирования. Однако в одном случае этот оператор очень удобен — в случае переходов между метками в операторе switch, в частности потому, что оператор switch в C# не позволяет „проваливаться“ сквозь метки case.»
И да, никого не надо увольнять.
Кратко: в C# применение оператора goto оправдано для:
1) Перехода между case-метками внутри switch-блока;
2) Для выхода из вложенных циклов.
p.s. Иначе такие примеры не приводились бы в официальных руководствах, причём без всякого рода предостережений, верно?
Однако, если гипотетически мои друзья выбрали бы заведомо более сложный путь — я бы недоумевал. Скорее всего, в предположении логичности их действий, они увидели бы в этом пути определённую выгодную сторону, которую я бы также попытался узнать и, возможно, перешёл бы на их способ/метод. В противном случае, если бы я не увидел долгосрочной выгоды в их решении, я бы посчитал их решение нелогичным, и выбрал бы путь, который, как вы говорите, помог бы мне «стать на голову выше их по скилам». Но тут надо заметить — моё стремление не в «стать на голову выше», а в «стать хорошим и востребованным специалистом», чтобы «рубить бабло» и, в том числе, иметь возможность покупать лицензионный софт.