Хватит пропускать мелкие детали

Question

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

Есть ли еще кто-нибудь, у кого была проблема, когда они впервые начинали пропускать некоторые детали, которые вызывают большие проблемы? Существуют ли какие-либо привычки или поведение, которые помогли вам преодолеть это?

Answer 1

Хорошее суждение приходит из опыта.

Опыт исходит из неправильного суждения.

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

Answer 2

Шаблоны - разрабатывайте или заимствуйте и ИСПОЛЬЗУЙТЕ шаблоны в своей работе. Некоторые примеры шаблонов: согласованное использование имен переменных, согласованное расположение для увеличивающихся счетчиков, согласованное размещение отчетов об ошибках и т. Д.

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

void MyMethod(String some_input)
{
   if (some_input == null)
   {
      some_input = "";
   }
}

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

void MyMethod(String some_input) {
  if (some_input == null) {
    some_input = "";
  }
}

Если где-то есть пропавшая скобка, то ее поиск займет очень много времени!

Answer 3

Всегда придерживайся принципа «Не усложняй» !! У вас меньше шансов на ошибку, если вы все упростите.

RWendi

Answer 4

Комментируйте хорошо.

Хорошо разнесите ваш код.

Имеют значимые имена переменных.

Answer 5

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

Answer 6

Мой единственный совет, который еще не упоминался и который помогает мне на регулярной основе, заключается в следующем: прежде чем я сделаю какие-либо существенные изменения, будь то код или документация, я всегда буду делать перерыв на 10-15 минут, прежде чем на самом деле завершение изменения. Обычно перерыв позволяет мне приходить в себя обновленным и, что более важно, не так, как инвестировано в изменение, и большинство моих вещей становятся очевидными из-за этого. Это обычно более полезно, когда вы единственный человек, работающий над чем-то, в противном случае вы можете просто получить экспертную оценку, которая обычно выше.

Answer 7

Как правило, ОГРОМНЫЕ ошибки возникают из-за того, что вы начинаете думать и писать программы. У меня работают 2 программиста, и вот что я настаиваю на том, чтобы они это делали. Это имеет большое значение.

Нарисуйте экран, который вы проектируете, на бумаге и определите, как все работает, насколько это возможно, прежде чем кодировать. Покажите это своему боссу / клиенту / кому-то еще. Объясни им это. Заставь их критиковать.

Никогда не начинайте писать код, пока вы не подумали об этом как об UML. Вам не нужно быть экспертом по UML, но диаграммы классов показывают:

1. Наследование
2. Агрегирование (например, этот сайт состоит из пользователей, пользователи создают несколько сообщений, сообщения могут иметь несколько комментариев от других пользователей)

Будет иметь огромное значение, если вообще не думать об этом.

Сохраняйте свои функции небольшими - не более 30 строк, часто меньше. Это поможет вам структурировать ваш код.

Answer 8

1. Не бойтесь ошибок - это лучший способ узнать что-то новое
2. Это очень важно иметь еженедельный просмотр кода - с профессионалом
3. код дома - это поможет вам улучшить себя быстрее
4. читайте чужой код - открытый исходный код - лучший способ узнать что-то новое

Answer 9

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

публичная строка GetName (int custID) {

        // Create local variables

        // Get the connection string from the config file

        // Create Try Catch Finally block

        // Create SQL parameters 

        .... etc

    }

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

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

Answer 10

Я верю в простую вещь.

Код один раз, код правильный.

И чтобы получить это (для меня в любом случае), мне нужно полностью мысленно представить проблему, прежде чем что-то делать. Если я не понимаю проблему полностью, я очень не хочу продолжать.

Тем не менее, иногда вам нужно пересечь черту и просто посмотреть, что на другой стороне, не зная.