Статья:
As is или история о том как не надо писать код

Автор(ы): Владислав Чистяков (VladD2)
Дата: 18.12.2004
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

Авторы:
Владислав Чистяков (VladD2)

Аннотация:
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Аннотация:
ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

Круто Надо бы еще тех, за кем было замечено чрезмерное использование as, повесить на доску всеобщего презрения. А может, даже из партии исключить?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Круто Надо бы еще тех, за кем было замечено чрезмерное использование as, повесить на доску всеобщего презрения. А может, даже из партии исключить?

Ну, то проблемы работодателя.

Написать, что ли, статью про опасности, возникающие при неявных приведениях типов в С++, про использование using в С# или про то, что нужно проверять делитель на ноль

Здравствуйте, Andy77, Вы писали:

A>Написать, что ли, статью про опасности, возникающие при неявных приведениях типов в С++, про использование using в С# или про то, что нужно проверять делитель на ноль

Напиши. Особенно интересно последнее.

PS

Не все что кажется тебе банальным и само собой разумеющимся расценивается так же другими. Вот ты думашь, что тебе мика столько оценок наставил? Это он не согласен с сутью статьи, но боится открыто поставить минус.

Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Авторы:
ВЧV> Владислав Чистяков (VladD2)

ВЧV>Аннотация:
ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

На всякий случай — это пока не статья, а ее анонс в журнале. В какой-то степени она является следствием этого обсуждения здесь

Автор: AndrewVK
Дата: 22.06.04

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>>Аннотация:
ВЧV>>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

ВВ>Круто Надо бы еще тех, за кем было замечено чрезмерное использование as, повесить на доску всеобщего презрения. А может, даже из партии исключить?

Какой....

Автор: adontz
Дата: 05.08.04

Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Статья:


ВЧV>Авторы:
ВЧV> Владислав Чистяков (VladD2)

ВЧV>Аннотация:
ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.


Eto to chem ja polzuyus .
http://www.idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip
Ob operator(e) as na stranize 8. Ob avtore chitay zdes http://www.softwarelegends.com/legends.html

Здравствуйте, Владислав Чистяков (VladD2), Вы писали:

ВЧV>Статья:


ВЧV>Авторы:
ВЧV> Владислав Чистяков (VladD2)

ВЧV>Аннотация:
ВЧV>Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

Хорошая статья. Я согласен с ее идеей.

Что не понравилось:

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

2. В статью попал факт личностного конфликта в виде такого легкого намека:

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

В программе не было ни одного приведения типов, но постоянно встречались as. Мои попытки объяснить порочность данной практики были тщетны. Упорство, с которым отстаивалось применение as-ов, было воистину достойно лучшего применения.

Мне показалось, что это была попытка (возможно ненамеренная) кого-то уязвить.

Здравствуйте, dshe, Вы писали:

D>Мне показалось, что это была попытка (возможно ненамеренная) кого-то уязвить.

Прочитай этот тред повнимательней и обрати внимание на имена

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dshe, Вы писали:

D>>Мне показалось, что это была попытка (возможно ненамеренная) кого-то уязвить.

А>Прочитай этот тред повнимательней и обрати внимание на имена

Мне это не интересно.

Здравствуйте, dshe, Вы писали:

D>Мне это не интересно.

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

Не совсем понятно, почему так легко отметается все-таки основной аргумент — скорость, а упор делается на в общем-то практически и не аргумент (эстетизм).
Насколько я понимаю, использование as с обязательной проверкой на null не менее надежна, чем old-style type cast. По скорости тут выигрыш не только благодаря тому, что as отрабатывает быстрее, но и благодаря тому, что пробрасывание исключения — это более дорогая операция, чем проверка на null.
Я бы сказал, что сравнение as и old-style type cast по сути сводится к сравнению бросания исключения и возврата кода ошибки (скорость vs удобство и элегантность дизайна).

Здравствуйте, Alik, Вы писали:

A>Насколько я понимаю, использование as с обязательной проверкой на null не менее надежна, чем old-style type cast.

Но кода при этом больше.

A> По скорости тут выигрыш не только благодаря тому, что as отрабатывает быстрее,

Только в 1.1. Там же для 2.0 тесты должны быть.

A> но и благодаря тому, что пробрасывание исключения — это более дорогая операция, чем проверка на null.

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

A>Я бы сказал, что сравнение as и old-style type cast по сути сводится к сравнению бросания исключения и возврата кода ошибки (скорость vs удобство и элегантность дизайна).

Там в статье, насколько я помню так и сказано — as применять в том случае, если ошибка приведения это нормальная логика программы, а не исключительная ситуация. Заменять же исключительную ситуацию кодоб ошибки не очень умно.

Здравствуйте, Alik, Вы писали:
A>Не совсем понятно, почему так легко отметается все-таки основной аргумент — скорость, а упор делается на в общем-то практически и не аргумент (эстетизм).
В статье сказано:

Но можно ли жертвовать надежностью ПО ради скорости?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Alik, Вы писали:
A>>Не совсем понятно, почему так легко отметается все-таки основной аргумент — скорость, а упор делается на в общем-то практически и не аргумент (эстетизм).
_FR>В статье сказано:
_FR>

Но можно ли жертвовать надежностью ПО ради скорости?

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

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

Здравствуйте, Mika Soukhov, Вы писали:
A>>>Не совсем понятно, почему так легко отметается все-таки основной аргумент — скорость, а упор делается на в общем-то практически и не аргумент (эстетизм).
_FR>>В статье сказано:

Но можно ли жертвовать надежностью ПО ради скорости?

MS>Вообще, чтобы такое заявлять, нужно держать на руках список аналитических данных, в которых говорить, что С-привидние типов даст прирост в плане надежности ошибок больше, чем as. Без таких данных говорить о том, что лучше, а что хуже — поменьшей мере наивно.
MS>Если гнаться за такими вещами, то рано или поздно написанный код скатиться к уровню параноидальному, ибо все ошибки отследить невозможно.

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

Здравствуйте, _FRED_, Вы писали:

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

Очевидно, что ошибка в production как в результате несловленного исключения, так и в результате не проверки на null — абсолютно неприемлемое поведение программы.
Посему, если мы будет говорить про написание качественного кода, т.е. кода, в котором предусматривается проверка на null или ловится исключение, надежность одинаковая, а по скорости выигрывает as. Вроде бы все очевидно. Совершенно не понятно, о чем спорить и это ИМХО тема вопроса в FAQ на 10-15 строк, а не статьи на несколько экранов.

Здравствуйте, Alik, Вы писали:
MS>>>Если гнаться за такими вещами, то рано или поздно написанный код скатиться к уровню параноидальному, ибо все ошибки отследить невозможно.
_FR>>Очевидно, что сообщение в рантайме об ошибке приведения типов даст более правильную информацию, нежели ошибка обращения по нулевому поинтеру что позволит гораздо точнее локализовать место её возникновения и, соответственно, исправить.
A>Очевидно, что ошибка в production как в результате несловленного исключения, так и в результате не проверки на null — абсолютно неприемлемое поведение программы.

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

A>Посему, если мы будет говорить про написание качественного кода, т.е. кода, в котором предусматривается проверка на null или ловится исключение, надежность одинаковая, а по скорости выигрывает as. Вроде бы все очевидно. Совершенно не понятно, о чем спорить и это ИМХО тема вопроса в FAQ на 10-15 строк, а не статьи на несколько экранов.

В FAQ не обосновывают выводы, не задаются сакраментальными вопросами, а говорят, как поступать в некоторой ситуации.
Когда наболело и требуется поспорить "10-15 строк" в стиле FAQ я счёл бы неуважением к оппонентам. Автор же не поленился написать тесты, вспомнить ссылки и поискать цитаты, добиться в редколлегии права провести свой взгляд в массы ...

P.S. Если кто считает тесты не справедливыми а ссылки и цитаты неуместными, то это отдельный разговор, для которого топик, по всей видимости, и создавался.

Здравствуйте, Andy77, Вы писали:

A>Написать, что ли, статью про опасности, возникающие при неявных приведениях типов в С++, про использование using в С# или про то, что нужно проверять делитель на ноль

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