Про плохое программирование.

[Romanzes]

Источник: http://www.codeproject.com/KB/scrapb...ogramming.aspx
Автор Оригинала (англ.): Alison P

Вступление.
Недавно я заметил, что отдельные личности настаивают на том, что нужно писать красивый, грамотный, хорошо документированный код, который к тому же легко понять. Поэтому я решил выделить время на то, чтобы написать статью о важнейших приемах очень плохого программирования. Помните, что 2 главные вещи при написании действительно ужасного софта заключаются в том, чтобы включить в программу как можно больше багов, и вместе с тем сделать код настолько запутанным, чтобы эти баги было невозможно найти и исправить. Таким образом, вы сможете поиздеваться сразу и над пользователями, и над программистами.
Я обещаю, что если вы будете следовать этим простым правилам, то пользователи и программисты будут очень долго вспоминать вас добрыми словами.

1. Отключите все предупреждения компилятора.
Если вы действительно хотите написать быдлокод, то это то, с чего следует начать. В конце концов, вы же не собираетесь весь день слушать нытье компилятора? Все настоящие программисты всегда полностью отключают эти предупреждения.

2. Переменные.
Новички, запомните, что ВСЕ переменные должны быть глобальными. Ведь гораздо легче держать их все в одном месте. Когда вы станете более продвинутым, используйте глобальные переменные в разных местах в качестве локальных, так вам будет легче создать труднонаходимые баги.

3. Функции.
Старайтесь всегда избегать использования функций. Лучше сразу написать огромный кусок кода, чем выполнять нудную работу по разделению его на функции, и передаче параметров в них.

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

5. Названия переменных для начинающих.
Вы также можете повеселиться, придумывая имена переменных, попробуйте дать переменной самое малозначащее имя, какое только можно (одно из моих любимых – Fred). Но не забывайте оставлять немного осмысленных имен, чтобы озадачить других программистов.

6. Дополнительные приемы наименования переменных.
Попробуйте придумать несколько почти одинаковых имен для совершенно разных переменных. Также хороша идея создать 2 переменных с одинаковым именем, но одну, заканчивающуюся на «l», а другую – на «1». Например, Slopel и Slope1. Однако, вы достигнете лучших результатов, если имя переменной будет противоположно по значению роли переменной в программе. Например, можно использовать имя Horizontal, когда переменная должна называться Vertical, и наоборот. Это очень порадует того, кто после нескольких часов разгадает ваш хитрый прием.

7. Инициализация.
Играйте в программистскую лотерею – позвольте переменным при инициализации иметь случайное значение из памяти компьютера. Будет весело!

8. Проверка допустимых значений.
Позвольте юзеру вводить в программу любое значение, если они введут какую-нибудь чепуху, программа сломается. Ну, а что они ожидали?

9. Комментарии.
Если вы новичок, лучше всего будет избегать комментариев во всех случаях, они занимают полезное пространство, и на их написание тратится много времени. Когда вы станете более продвинутым, вы научитесь писать вот такие комментарии:

i++; //увеличить i

Самые продвинутые комментарии выглядят примерно так:

i++; //проверка в куриной последовательности

10. Стиль кода.
Сделать свой стиль кода по-настоящему плохим – настоящее искусство. Самое важное здесь – НИКОГДА не быть последовательным! Какой бы стиль вы ни выбрали, меняйте его регулярно. Продвинутые программисты должны помнить, что следует использовать одинаковый стиль достаточно долгое время, прежде, чем переключиться на что-то другое, чтобы читающий мог привыкнуть к нему.

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

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

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

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

[moka]

Классный стиль написания статьи
Молодцом за перевод!

[Tronix]

Спасибо за статью.
Но есть спорные моменты, например:

3. Функции.
Старайтесь всегда избегать использования функций. Лучше сразу написать огромный кусок кода, чем выполнять нудную работу по разделению его на функции, и передаче параметров в них.

В случаях, когда требуется повысить быстродействие программы от функций надо избавляться и писать все одним блоком. Особенно не следует вызывать функции из inner_loop'ов. Ибо вызов функции это: сохранение всех регистров в стек, прыжок на неведомый (для предсказания ветвлений процессора) адрес кода, выгрузка всех регистров из стека и опять прыжок в основной код.

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

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

5. Названия переменных для начинающих.
Вы также можете повеселиться, придумывая имена переменных, попробуйте дать переменной самое малозначащее имя, какое только можно (одно из моих любимых – Fred). Но не забывайте оставлять немного осмысленных имен, чтобы озадачить других программистов.

Насколько мне известно, например в Java, все имена переменных сохраняются в конечном байт-коде (бинарнике проще говоря). Из этого следует по крайней мере то, что если давать переменным слишком длинные имена возрастает конечный бинарный файл в размере (актуально для мобильных приложений, например). Так-же есть мнение что в J2ME к длинным переменным увеличивается время доступа, нежели к коротким.

А так все правильно, посмеялся. Хороший перевод, хорошая статья.

[Romanzes]

Насколько мне известно, например в Java, все имена переменных сохраняются в конечном байт-коде (бинарнике проще говоря). Из этого следует по крайней мере то, что если давать переменным слишком длинные имена возрастает конечный бинарный файл в размере (актуально для мобильных приложений, например). Так-же есть мнение что в J2ME к длинным переменным увеличивается время доступа, нежели к коротким.

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

[ABTOMAT]

А автоматические обфускаторы, оптимизаторы, разворачиватели циклов, in-line-функции - нэ?

[Romanzes]

Естесственно, обфускатор все это делает.