Студопедия

КАТЕГОРИИ:

АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника


Рекомендации. Рекомендательные правила, положительные или отрицательные, несут в себе риск бесполезности.




Рекомендательные правила, положительные или отрицательные, несут в себе риск бесполезности.

Чтобы отличить принцип от обычной банальности ( platitude ), следует рассмотреть отрицание: для принципов отрицание имеет смысл независимо от того, согласны вы с ним или нет. Например, часто цитируемый методологический совет: "Используйте имена переменных, имеющие смысловое содержание", - не является принципом с этой точки зрения, так как никто в здравом уме не будет выбирать бессмысленные имена переменных. Для превращения этого правила в принцип, следует задать точный стандарт именования переменных. Конечно, поступив так, вы обнаружите, что некоторые читатели не будут согласны с предложенным стандартом, - вот почему банальности более комфортабельны, но методологи должны брать на себя подобные риски.

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

Следующее предписание позволит избежать этого риска, сохраняя нашу честность:

Рекомендательные правила: принцип методологии Создавая рекомендательные правила (положительные или отрицательные), используйте принципы, а не банальности. Для того чтобы отличить одно от другого, используйте отрицание.

Вот пример отрицательной рекомендации, извлеченный из обсуждения преобразования типов ( casts ) в одном из справочников по C++:

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

Все это не сопровождается пояснением, как же выяснить, что " программист действительно был прав ". Так что читателю предлагается не использовать некоторый механизм языка ( type casts ), предупреждая, что это может быть опасно и "приводить к сюрпризам ", неявно заявляя, что иногда этот механизм следует применять, не давая никакого указания, как различать случай легитимного использования.

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


Поделиться:

Дата добавления: 2014-12-03; просмотров: 186; Мы поможем в написании вашей работы!; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2024 год. (0.006 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты