В компаниях, разрабатывающих программное обеспечение, применяются различные стандарты кодирования, целью которых является повышение надежности, переносимости и, что самое важное, читабельности кода, написанного совместно разными разработчиками.
Два примечательных примера - это MISRA C и стандарт C ++, разработанный для проекта JSF .
Они обычно имеют следующую форму, после тщательного определения того, что означают слова «должен», «должен», «должен», «может» и т. Д.
Пример:
Правило 50: Переменные с плавающей запятой не должны проверяться на точное равенство или неравенство.
Обоснование: поскольку числа с плавающей запятой подвержены ошибкам округления и усечения, точное равенство может быть не достигнуто, даже когда ожидается.
Эти стандарты кодирования накладывают ограничения, как правило, на код, который был бы законным с точки зрения компилятора, но он опасен или нечитаем, и поэтому «считается вредным».
Теперь давайте злоупотребим этим!
Вы приняты в качестве члена небольшого комитета по стандартизации в вашей компании, который предназначен для разработки новых стандартов кодирования, которые должен будет использовать каждый разработчик в компании. Без ведома других вы тайно используете зловещую организацию и ставите своей целью саботировать компанию. Вы должны предложить одну или несколько статей в стандарт кодирования, которые позже будут мешать разработчикам. Тем не менее, вы должны быть осторожны, чтобы не сделать это сразу очевидным, иначе вы рискуете не быть принятым в стандарт.
Другими словами, вы должны ввести в стандарт кодирования правила, которые выглядят законно и имеют хорошие шансы быть принятыми другими членами комитета. После того , как проекты запускаются и бесчисленное количество человеко-часов , вкладываются в коде, вы должны быть в состоянии злоупотребить этим правилам (например, по техническим причинам , или по оченьбуквальная интерпретация) помечать код нормального и хорошего качества как противоречащий стандарту. Поэтому они должны приложить немало усилий, чтобы переработать его, и правила будут мешать им с этого момента, но поскольку правила активны в течение достаточно долгого времени, чистый импульс сохранит эти роли в живых, и поскольку существуют значительные конфликты интересов между различными уровнями управления, другие менеджеры, вероятно, будут поддерживать правила (они были бы глупы, чтобы признать свою ошибку!), что мешает компании! Mwahahahahaaa!
счет
Ответ, получивший наибольшее количество голосов примерно через 2 недели после первой действительной заявки, выигрывает. У меня есть идея для хорошего ответа, но я опубликую ее только через несколько дней, так как кто-то другой может прийти к той же идее, и я не хочу лишать их удовольствия. Конечно, мой собственный ответ не будет принят выше любого другого, независимо от оценки.
Избирателям предлагается оценивать ответы, основываясь на том, насколько хорошо лазейки скрыты и насколько разочаровывают разработчиков.
Правила и положения
- Правило или правила должны выглядеть профессионально, как в приведенном выше примере
- Правила должны выглядеть подлинно (поэтому такие вещи, как «все переменные должны содержать хотя бы одно подчеркивание, одну заглавную букву, одну строчную букву и две цифры» , не принимаются. Они действительно будут мешать разработчикам, но, скорее всего, не будут приняты комитет), и если их заслуга не сразу очевидна, вы должны дать хорошее обоснование.
- Вы должны быть в состоянии найти способ использовать / злоупотреблять вашими правилами, чтобы саботировать разработчиков позже. Вы можете злоупотреблять любой двусмысленностью в других правилах, или вы можете использовать несколько правил, которые сами по себе безвредны, но однажды объединены!
- Вы должны опубликовать объяснение в тегах спойлера в конце вашего сообщения о том, как вы можете злоупотреблять правилами
- Используемый язык не должен быть эзотерическим. Язык, широко используемый в реальных проектах, должен быть выбран, поэтому предпочтение отдается языкам с синтаксисом, подобным С (вместо таких вещей, как Golfscript).