Подтвердить что ты не робот

Где источник для Нимана 13 Минимально достаточных заповедей?

У меня есть страница (стр. 1) от 2 февраля 1989 года, которую представил мне мой бывший босс, в котором излагаются Ниман 13 Минимально достаточные заповеди для программирования. (Он узнал, что они были датированы, сделав это скорее частью археологии, чем современным набором рекомендаций.) Если вы их не видели, они выглядят следующим образом:

  • Вы должны адекватно прокомментировать свой код, чтобы объяснить, что вы намереваетесь. Человек не думает только мнемоникой.
  • Вы должны приравнивать числовые константы к значимым именам символов. Говорите четко и избегайте языческих значков.
  • Опишите все входы и выходы в своих модулях. Будьте добры к своим коллегам по программному обеспечению и sistren, которым, возможно, придется поддерживать свои модули.
  • Вы должны адекватно описать свои исправления. Грех ожидать, что ваш пэрен станет читателем разума. Разумеется, чтение - это грех.
  • Вы должны предоставить псевдокодные объяснения вашего кода сборки. Поистине, сборка не является Cobol.
  • У вас будет только одна запись и одна точка выхода на модуль. Тот, у кого много точек входа и выхода, должен ожидать, что их тела будут развиваться одинаково.
  • Вы должны разработать свой код до его разработки. Воистину, действительно.
  • Проводите обзоры своего кода с вашим сверстником. Благословенны кроткие, ибо они наследуют объектный код.
  • Запишите свой дизайн и сделайте документацию доступной всем, кто поддерживает код. Поистине, тот, кто отказывается отложить операционные системы навсегда в аду.
  • Ты сможешь принять осмысленную критику их кода. Если вам стыдно за свой код, вы должны стать профессиональным котелом.
  • Перед тем, как поместить его в библиотечный контроль, вы должны проверить свой код (sic). Одна часть, оставшаяся вне Библии, была там, где Иов был испытан Богом, вынудив отлаживать крупную программу ассемблера 8096, которая была частью контроллера двигателя деления. Все это не было проверено перед выпуском. Чтобы ухудшить ситуацию, Job должен был использовать инструменты Intel.
  • Во избежание использования глобальных структур данных, где это возможно. Башни будут называться Вавилон, программы не должны.
  • Вы должны использовать язык высокого уровня, когда ваши программисты сборки не могут сопоставить эффективность оптимально скомпилированного кода конца двадцатого века. Остерегайтесь ложных богов, которые считают, что сборка всегда более эффективна (относительно скорости и размера), чем то, что могут создавать хорошие компиляторы. Вам должно быть очень хорошо с дизайном, а также с кодированием, чтобы действительно использовать язык ассемблера.

Я просмотрел интернет, не показал ничего об источнике этих заповедей или Нимане, и он убил меня, пытаясь узнать больше об этом и о любых других бит, которые он, возможно, должен был сказать. Единственный другой ключ, который у меня есть, это то, что в левом нижнем углу есть инициалы "DEN" - я предполагаю, что N для Нимана, но мне больше нечего идентифицировать текст. Таким образом,

а. Кто такой Ниман? (Программист? Учитель? Консультант? Случайный парень в компании?)

В. Из чего была эта страница? (старый справочник по программированию? какое-то руководство компании? Некоторые BBS в день?)

С. Где остальное? (Есть ли еще? Что еще есть? Было ли это самостоятельным?)

В ответ на комментарии мой босс с тех пор прошел, но до этого он был в бизнесе долгое время, greybeard и все такое. По цвету бумаги я вполне уверен, что дата (1989) - это примерно дата, когда она была напечатана.

4b9b3361

Ответ 1

Дональд Э. Ниман, найденный Марком, является правильным. Я должен знать, потому что это я. Это 22-летняя вещь, которую я написал в то время, когда я был Cummins Electronics, Inc., в Columbus, IN. Это немного устарело, и с тех пор я чему-то научился, поэтому его нужно принимать за пресловутое зерно соли. Дональд Э. Ниман, Феникс, Аризона.

Ответ 2

Там был хороший шанс, что мужчина был Дональд Э. Ниман.

  • При поиске Дональда E. Ниман, вы получаете несколько результатов:

    • Он был инженером-программистом в Safetran Systems Corporation в Ранчо Кукамонга, Калифорния.
    • Он активно работал с BOINC, занимающимся SETI @Home около 1999 года.
    • У него было несколько активных сообщений на нескольких форумах по математике.
    • У него было одно сообщение в гостевой книге сайт для сбора советских калькуляторов (вам может понадобиться кеш Google, который, t для меня)
  • Поиск "Дональд Ниман" показывает:

    • В настоящее время он находится в Финиксе, штат Аризона, согласно Facebook.
    • Его профиль Google показывает, что он действительно жил в Ранчо Кукамонга
    • У него есть один 51-летний друг на Plurk - поэтому он, вероятно, тоже в этом возрастном диапазоне, в соответствии с написанием небольшой "список заповедей" в 1989 году.
    • Имя, помещенное на микрочип, идущий в космос

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

У него есть пара точек контакта, которые вы можете получить в Интернете - вы могли бы схватить его и узнать, действительно ли он настоящий автор. Кроме того, вы могли бы узнать, жил ли он в городе, где ваш бывший босс, возможно, работал в 1989 году, со своей страницы профиля Google.

Ответ 3

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

Но я почувствовал вдохновение переписать некоторые из них:

  • Вы должны написать код, который можно прочитать без комментариев.
  • Вы должны приравнивать числовые константы к значимым именам символов в пределах разумного. x > ZERO не является разумным.
  • (как есть)
  • Вы должны использовать контроль источника, а не размещать комментарии редакции в источнике.
  • Не записывайте сборку, если ваше имя Стив Гибсон.
  • Вы должны использовать оговорки охраны и исключения, если это необходимо.
  • Вы должны разработать свой код, но TDD - это дизайн.
  • (как есть)
  • Не создавайте документацию без причины и не позволяйте документации устаревать.
  • (как есть)
  • Вы должны обеспечить, чтобы ваш код компилировался, и что ваши модульные тесты существуют и проходят до помещения его в исходный контроль. Буйки могут быть нанесены тем, кто нарушает сборку.
  • Во избежание использования глобальных структур данных, где это возможно. Сюда входят синглтоны.
  • Вы избегаете оптимизации без профилирования, исповеди и самобичевания.