Прекратите пропускать незначительные детали

Сделайте все, что Вы можете для понимания ошибок. Запишите то, что пошло не так, как надо, все, что Вы пытались зафиксировать ошибку, и что наконец работало. Я использую этот метод, чтобы вынудить меня замедлиться и прекратить предполагать вслепую. Если Вы будете делать это достаточно долго, то Вы разработаете ориентированную на деталь привычку работы, которая должна уменьшить Ваши ошибки.

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

if fred==bill dosomethingtofred() else dosomethingtobill();

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

if (fred==bill) {
  dosomethingtobill();
}
else {
  dosomethingtofred();
}

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

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

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

Все мы делаем ошибки. Гении - те, кто просто сохраняет их на разделочной доске.

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

Практика - чем больше кода Вы пишете, тем больше опыта Вы получите

код Повторного использования - код, который использовался, много маловероятно для содержания дефектов

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

, Тестирование - смотрит на поблочное тестирование TDD (не традиционное поблочное тестирование) - которые означают документировать ожидаемое поведение кода и создавать код, который тестирует его. Больше кода означает больше опыта, больше автоматизации, более высокая уверенность

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

Все мы делаем глупые ошибки, потому что мы люди.

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

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

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

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

общественность представляет GetName в виде строки (интервал custID) {

        // Create local variables

        // Get the connection string from the config file

        // Create Try Catch Finally block

        // Create SQL parameters 

        .... etc

    }

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

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

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

Код однажды, кодируйте право.

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

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

Обычно БОЛЬШИЕ ошибки прибывают из дайвинга в и записи программного обеспечения до размышления об этом. Я нанимаю 2 программистов, и вот то, что я настаиваю, чтобы они сделали. Это имеет большое значение.

Тянут экран, который Вы разрабатываете на бумаге и определяете, как вещи работают как можно больше перед кодированием. Еще покажите его своему boss/client/someone. Объясните это им. Заставьте их критиковать его.

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

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

, будет иметь значительное значение к не размышлению об этом вообще.

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

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

Растягивают Ваш код хорошо.

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

Избегайте желания начать писать код, прежде чем Вы полностью поймете проблему. Если Вы только поймете часть проблемы, то Вы, вероятно, проведете время, переделав дизайн позже. Объясните большое изображение в своем уме или на бумаге, затем начните кодировать.

Всегда имейте, "Сохраняют Это Простым" отношением!! У Вас есть меньше, случайно натыкаются на делание ошибок, если Вы сохраняете вещи простыми.

RWendi

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

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

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

Вы делаете хорошее начало - распознающий, что Вам не выяснили все это. Ни один из нас не делаю.

Удостоверяются, что Вы понимаете домен - который устранит некоторые ошибки сразу. Знайте то, что Вы решаете и затем идете о попытке разработать решение.

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

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

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

МНОГОЕ из этого прибудет из опыта, по существу со времени, делая то, что Вы делаете и учение на Ваших ошибках!

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

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

Я добавлю, что другое голосование для "осуществления делает прекрасным", но с небольшим admendment:

прекрасный практика делает прекрасным - связанное высказывание является "практикой, делает постоянным", так, другими словами, удостоверяются, что то, что Вы практикуете, является хорошими привычками кодирования, которые сокращают ошибки:

• поблочное тестирование
• читаемый код, форматирующий
• полезные имена переменной
• управление исходным кодом для истории пересмотра

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

Обзор кода однорангового узла и поблочное тестирование. Только опыт поможет Вам прекратить делать ошибки, но эти вещи помогут Вам узнать об ошибках, что Вы делаете рано.

Это похоже со всем остальным, что Вы сделаете в жизни. От записи себя на жаровне в локальном магазине фаст-фуда, к тому, чтобы быть предпринимателем на его 3-м запуске.

Делают ошибки , учатся от них, и лучше самостоятельно - не игнорируют их .

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

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

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

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

тот же метод записанное использование общей, но плохой практики было бы похоже на это:

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

, Если существует недостающая фигурная скобка где-нибудь, это является очень трудоемким для нахождения его!

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

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