В основе романа Гэри Селдон, который разработал науку, основанную на психологии и истории, выразив её в математических законах, в дальнейшем предсказывая кризисы человечества на протяжении 10-15 т.л. (если мне не изменяет память).
Данное высказывание рассматривалось через призму защитного программирования, где каждую вашу функцию мог вызвать любой участник проекта из любого места.
Пока читал книгу (оригинал, а не вырезки выше) в каждой следующей главе ждал чего-то нового, неизведанного, а на деле получались только прописные истины, где в каждом скользком вопросе (оформление фигурных скобок в коде, кол-во точек выходов из функции) автор отдавал право выбора читателю.
п.с. Да и картинки с обезьянками в конце каждой главы доставляли…
600€ за бессрочную однопользовательскую лицензию в России? И это после слов, очевидно одного из участников проекта:
«Продукт получился не самый простой и интуитивно-понятный, к сожалению это обратная сторона желания внести большую функциональность. Когда я сам в первый раз открыл, повозился полчаса, плюнул, закрыл.».
«Золотые правила» из книги, описывающие данную статью:
Учитесь давать объектам прозрачные имена — они должны ясно описывать то, что за ними скрывается.
Чтобы придумать хорошее имя, главное — четко понимать, для кого оно предназначено. Только в этом случае имя может стать осмысленным. Если не удается придумать хорошее имя объекту, спросите себя, понятно ли вам его назначение.
Ясность имени предпочтительнее его краткости.
Предпочтительней такое правило именования, которое различает имена переменных и имена типов.
Давайте функциям имена с внешней точки зрения, в виде фраз, выражающих действие. Описывайте логическую операцию, а не способ реализации.
Начинать писать никогда не рано, однако стоит излагать свои мысли, так, как если бы Вас попросили провести урок (лекцию) или выступить с докладом.
Представляете, если бы Вы вышли и сообщили большому залу слушателей или классу то, что Вы написали выше? Больше подходит на отличную защиту лабораторной или отчет о сделанной работе, чем интересную статью. Успехов :)
Кодер
Гуру
Псевдогуру
Высокомерный гений
Ковбой
Плановик
Ветеран
Фанатик
Монокультурный программист
Лодырь
Руководитель поневолец
А вот вам с 500 игнорируемыми предупреждениями действительно удачи.
п.с. Да и картинки с обезьянками в конце каждой главы доставляли…
«Продукт получился не самый простой и интуитивно-понятный, к сожалению это обратная сторона желания внести большую функциональность. Когда я сам в первый раз открыл, повозился полчаса, плюнул, закрыл.».
Я бы предпочёл http://www.axure.com/
Не знал о существовании подобных функций, но пользоваться всё равно не буду.
а в представлении:
Печально.
«Value cannot be null. Parameter name: source» на строке:
:(
Учитесь давать объектам прозрачные имена — они должны ясно описывать то, что за ними скрывается.
Чтобы придумать хорошее имя, главное — четко понимать, для кого оно предназначено. Только в этом случае имя может стать осмысленным. Если не удается придумать хорошее имя объекту, спросите себя, понятно ли вам его назначение.
Ясность имени предпочтительнее его краткости.
Предпочтительней такое правило именования, которое различает имена переменных и имена типов.
Давайте функциям имена с внешней точки зрения, в виде фраз, выражающих действие. Описывайте логическую операцию, а не способ реализации.
Качества хорошего имени:
1. Описательность
2. Техническая корректность
3. Идиоматичность
4. Тактичность (длина, стиль)
— Пишите код, который может прочесть нормальный человек, причем без напряжения. Компилятор как-нибудь справится.
Помещайте в код комментарии только в том случае, если не удается облегчить его понимание иными способами.
(с) Питер Гудлиф
Питер Гудлиф — Ремесло программиста. Практика написания хорошего кода
Представляете, если бы Вы вышли и сообщили большому залу слушателей или классу то, что Вы написали выше? Больше подходит на отличную защиту лабораторной или отчет о сделанной работе, чем интересную статью. Успехов :)