О каких ярлыках программирования Вы заканчиваете тем, что сожалели или отступление? [закрытый]

Разрешение Visual Studio выполнять привязку данных. Он работает большую часть времени, но иногда приводит к появлению тонких ошибок, на поиск и устранение которых уходит гораздо больше времени, чем при привязке данных вручную.

Чрезмерное использование макросов C / C ++. Я думаю, что это ловушка, когда большие проекты попадают в нечто большее, чем мелкие.

Не совсем ярлык, но: Написание класса String C ++, даже не учитывая возможность того, что кто-то другой имел такую ​​же идею. Тем не менее, это было хорошее упражнение, поскольку я узнал, что:

• Написание библиотеки не делает все программирование с этого момента. Может быть проще иметь библиотеку под рукой, но если понять семантику библиотеки сложнее, чем реализовать функциональность вручную, библиотека может оказаться довольно бесполезной.
• В C ++ есть много действительно полезных функций.
• В C ++ всегда отсутствует одна функция, которая мне действительно нужна.

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

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

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

Таким образом, веб-уровень вызывает делегат, интерфейс вызывает делегат, вызовы реализации, вызовы интерфейса службы, вызов реализации службы, вызовы интерфейса, вызовы интерфейса, вызов реализации и т. Д.

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

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

Если вы пишете hello world, просто напишите код и при необходимости увеличьте его объем позже.

Я думаю, что очевидным ответом на самый прискорбный программный "ярлык" будет gotos.

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

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

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