Так что теперь у вас есть проблема, если вы пишете библиотеку, которая будет использоваться как кодом старой школы, написанным с wchar_t , определённым как псевдоним для unsigned short , так и кодом новой школы, написанным с wchar_t как отдельным внутренним типом. Какой тип данных вам нужно использовать для строковых параметров?

Это перевод The sad history of Unicode printf-style format specifiers in Visual C++ .

Windows реализовала Unicode раньше, чем большинство других операционных систем. В результате решения Windows для многих проблем отличаются от решений, принятых теми, кто подождал, когда пыль осядет¹. Самым ярким примером этого является использование Windows UCS-2 в качестве кодировки Unicode. Тогда это была кодировка, рекомендованная консорциумом Unicode, потому что Unicode 1.0 поддерживал только 65"536 символов². Консорциум Unicode передумал пять лет спустя, но к тому времени было уже слишком поздно для Windows, которая уже выпустила Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 и Windows 95 - все из которых использовали UCS-2³.

Но сегодня мы поговорим о строках формата в стиле printf .

Это перевод If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited .

Предполагается, что вы будете вызывать функцию FlushInstructionCache , когда вы генерируете или модифицируете исполняемый код в run-time - чтобы процессор при выполнении вашего сгенерированного/модифицированного кода читал бы написанные вами инструкции, а не старые инструкции, которые могут остаться в кеше команд процессора.

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

Но в Windows NT функция FlushInstructionCache выполняет реальную работу, поскольку ей необходимо уведомить все остальные процессоры о необходимости очищать их кэши.

Однако если вы посмотрите на Windows 10, то вы обнаружите, что функция FlushInstructionCache выглядит как версия для Windows 95: она ничего не делает .

В чём тут дело?

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

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

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

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

    Имена переменных и подпрограмм должны быть информативными, т.е. такими, чтобы, глядя на них, другой программист мог догадаться о назначении переменной или подпрограммы. Плохо подобранное имя, дезориентирующее читателя, даже хуже, чем неинформативное имя, например X или A. Имена переменных должны состоять из букв нижнего регистра, кроме букв, с которых начинается второе или последующие слова, входящие в имя, например taxRate или numberOfCars . Имена подпрограмм должны начинаться с буквы верхнего регистра.

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

    Имя каждого компонента должно начинаться с префикса, состоящего из трех букв нижнего регистра и обозначающего тип компонента. Например, имя формы содержит префикс frm , поля ввода – edt , кнопки – btn и т.д. Буквы после префикса описывают назначение или содержание компонента. Например, поле ввода edtLastName содержит фамилию.

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

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

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

4.2. Правила разработки программ

    У всех вещественных констант цифры должны быть как слева, так и справа от десятичной точки, например 0.15, а не.15.

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

    Для преобразования вещественного значения в строку и обратно используйте процедуры Str () и Val (), а для целых значений в языке Object Pascal – функции StrToInt () и IntToStr () соответственно.

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

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

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

Обновлено 30.01.2009

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

0. САМЫЙ главный приоритет при разработке любой программы - это сохранение способности к развитию и повторному использованию . На практике только повторное использование кода может выявить ошибки и улучшить структуру (например, появление старых данных, но уже «нового» типа). Хорошая программа модифицируется перманентно.

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

а) безопасной (прежний не портится) модификации УЖЕ существующего кода,

б) возможность модификации и без исходного кода.

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

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

Хорошая читаемость;

Замкнутость (явность кода);

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

1.Оформление отдельных функций.

Пессимистическая точка зрения на входные переменные.

Bool тип функций с изначальным результатом FALSE .

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

Желательность присваивания выходных переменных в самом конце, а в теле функции работа происходит с «внутренними копиями этих переменных», так чтобы вызывающая функция получила NIL в качестве результата, если в теле функции произошла ошибка.

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

При ручном управлении памятью -- постоянное использования предварительного заполнения NULL .

2.Соглашения об именах переменных.и функций

Все глобальные переменные имеют начало “Gl ”.

Следовать стандартным наименованиям функций: Free,Create,Init, Get, Set, Is и т.д.

3.Методы фиксации ошибок.

Отладчик.

Организация потока сообщений об ошибках. Разные типы ошибок - идентификаторы опасных ошибок.

Использование trace файлов - чтобы грубо локализовать место краха.

Инструменты контроля утечек памяти (при ручном управлении памятью).

Способ согласования версий dll :хранение SizeOf (UsedRecord ) как поля в записи передаваемой на вход dll .

4. Пожалуй наиболее простой способ решить каким должен быть интерфейс, это "поиграться" с ним: написать примеры кода, который будет использовать этот модуль, до написания самого модуля. Эти "ненастоящие" примеры не пропадут, когда вы закончите разработку модуля. Вы можете просто переделать эти примеры в демо-программы, примеры для документации или использовать в качестве тестов для модуля. Ключевой принцип в том, чтобы писать код так, словно модуль уже существует, и подразумевая, что модуль имеет такой интерфейс, который наиболее удобен.

Все мы люди и нам свойственно ошибаться. И даже компьютеры ошибаются, если программа, за счет которой они работают, была написана с ошибкой. Чтобы помочь Вам избежать некоторых ошибок при написании программ на любом языке программирования я расскажу о некоторых правилах используемых при написании программ и о методах программирования. Соблюдение ниже описанных методов поможет не только избежать некоторых ошибок, но также предупредит их появление и упростит отладку Вашей программы. Все ниже приведенные примеры и код программ написаны на языке Visual Basic 6.0. Вы можете использовать материал данной статьи и для других языков программирования. Статья не привязывает Вас к какому-либо конкретному языку и является универсальной.

Метод проектирования программных средств

Для решения задач программирования используется "Метод проектирования программных средств". Этот метод состоит из нескольких этапов:

1. Определение условий задачи.
2. Анализ задачи.
3. Создание алгоритма решения задачи.
4. Реализация алгоритма.
5. Тестирование и отладка готовой программы.
6. Поддержка и обновление готовой программы.

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

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

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

Наверное, всем кто изучал программирование или информатику в учебных заведениях рассказывали, как нужно чертить блок-схемы. И наверняка большинство не любит их чертить. Ваш покорный слуга также относится к их числу. Но не стоит думать, что блок-схемы абсолютно бесполезны в программировании. Лично я никогда не черчу блок-схемы при разработке программ, но я умею хорошо это делать. И настоятельно советую Вам, научится чертить их лучше всех. Если Вы не научитесь самостоятельно и правильно чертить блок-схемы, Вы не сможете осознать суть того, как работает программа! Именно блок-схема позволяет наглядно и понятно (схематически) показать, как пошагово (построчно) выполняется программа. Ведь блок-схема это и есть алгоритм выполнения самой программы. А что такое алгоритм?

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

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

Четвертый этап метода проектирования программных сред заключается в записи созданного алгоритма в виде программы на определенно языке программирования.

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

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

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

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

Переменные

Имена переменных

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

For i = 1 to 10 Step 1
For j = 1 to 10 Step 1
dmsTable(i, j) = i * j
Next j
Next i

Если нам нужно сохранить в переменную чей-то год рождения. Назовите переменную "vblYearsBorn", а не "A". Старайтесь чтобы имя переменной отражало суть тех данных для хранения которых она предназначена, чтобы оно было интуитивно понятно. Пусть от этого имя переменной будет немного длинным, но зато это не даст вам запутаться и исключит повторное использования данной переменной в других вычислениях, для которых она не предназначена. Имя переменной желательно обязательно начинать с прописных букв vbl, от английского variable (переменная). Это особенно актуально в Объектно-Ориентированном Программировании (далее ООП). Так как имя переменной можно спутать с названием, какого либо объекта на форме (об этом пойдет речь ниже).

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

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

Объявление переменных

Некоторые языки программирования (например, Visual Basic) позволяют работать с переменными не объявляя их в коде программы. Я считаю это большой ошибкой и не солидностью языка программирования (но это не значит что этот язык программирования плох)!

Объявление переменной это определение ее типа и имени.

Dim vblFirstName as String (Visual Basic)
Var vblFirstName: String; (Turbo Pascal)
Char vblFirstName; (C++)

Т.е. мы как бы указываем программе, что будем использовать переменную с именем vblFirstName и тип данных этой переменной String (текстовый/литеральный).

Почему это важно (это касается только тех языков программирования, которые разрешают так делать. Например, если Вы не объявите переменную в С++ или Turbo Pascal-е, при компиляции будет сгенерирована ошибка, что используемая переменная не объявлена)? Все очень просто. Если мы не объявим переменную ей автоматически будет присвоен тип Variant, это значит что в переменную можно будет сохранять данные почти любого типа. Во-первых, мы сможем записать в переменную, которая хранит фамилию числовые данные или наоборот. ЭТО НЕПРАВИЛЬНО! Так как фамилия не может содержать цифры. Мы заведомо делаем в программе брешь, возможность для совершения ошибки. Вот такими ошибками и пользуются хакеры для взлома систем и прочее. Во-вторых, тип, присваиваемый автоматически, очень "много" занимает места в оперативной памяти. А хорошая программа должна как можно меньше весить. И не важно, сколько гигабайт оперативки у Вас на компьютере. В-третьих, явное объявление переменных позволит назначить им тот тип данных, который Вам необходим. И Вам будет намного легче узнать, какие переменные уже используются в программе. Достаточно будет посмотреть в начале программного кода или модуля, какие переменные уже заданы, а не перелопачивать весь код программы. Вы никогда не сможете повторно объявить уже объявленную переменную в одном и том же модуле, или перепутать их имена, а значить не используете переменную в тех вычислениях, для которых она не предназначена.

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

Инициализация переменных

После того как Вы объявили переменную её необходимо инициализировать, т.е. присвоить ей какое либо значение или обнулить. Это очень актуально для переменных используемых в вычислениях. Дело в том, при объявлении переменной для нее выделяется (резервируется) память. Резервирование памяти не отчищает ячейки от значений, которые ранее в них хранились, поэтому если за объявлением переменной не следует её инициализация, то текущее значение этой переменной будет непредсказуемым, а не нулевым, как думают многие. Не обязательно, что именно так и будет, но если это произойдет причину неправильных вычислений порой трудно выявить, так как код программы верен синтаксически и логически, но все равно вычисления идут неверные.

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

vblSum = 0
For I = 1 to 10 Step 1
vblSum = vblSum + i
Next i

Или присвойте ей единицу, если переменная используется, как множитель или делитель.

vblSum = 1
For I = 1 to 10 Step 1
vblSum = vblSum * i
Next i

Если это строковая переменная просто отчистите ее.

vblFirstName = ""

Лично я всегда инициализирую переменные, даже если в следующей строке присвою ей другое значение.

Глобальные и локальные переменные

Все переменные имеют свою область видимости в зависимости от того, как Вы их объявили. Переменные могут быть локальными и глобальными.

Локальные переменные - это переменные объявленные внутри какой-либо функции (подпрограммы). Они видимы только в пределах данной функции и не могут быть непосредственно вызваны из основного текста программы. Когда выполнение программы возвращается из функции к основному коду программы или другой функции, локальные переменные удаляются из памяти.

Глобальные переменные - это переменные, определенные вне тела какой-либо функции (для ООП, переменные объявленные в модулях проекта). Эти переменные имеют глобальную область видимости и доступны из любой процедуры, функции в подпрограмме.

Очень часто возникают ошибки при использовании глобальных переменных.

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

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

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

Константы

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

Const conPi = 3.14159265

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

Структурное программирование

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

Операторы начала и конца цикла пишутся строго друг под другом, а все операторы внутри цикла чуть правее. Все отступы делаются с помощью табуляции (клавиша Tab). Точно также пишутся логические схемы. Благодаря такому написанию ваша программа становится более читабельной и легкой для восприятия. Также облегчается отладка программы. Вы можете сами сравнить приведенный ниже пример, написания кода по принципу структурированного программирования и без него. Пример приведен на языке Turbo Pascal (часть кода сортировки массива).

Пример "Структурированный код":

For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
vblStuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;

Пример "Обычный код":

For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
stuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;

Какой вариант более читабелен и понятен? Несомненно, первый.

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

Ошибки

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

Ошибки, возникающие в процессе работы программы можно разделить на несколько типов:

1. Синтаксические ошибки
2. Ошибки времени выполнения
3. Логические ошибки

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

Ошибки времени выполнения выявляются компьютером во время выполнения программы. Подобные ошибки имеют место, когда программа дает компьютеру указание выполнить неверную операцию (например, деление на ноль или манипулировать неописанными или неверными данными).

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

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

Умелое использование всех этих методов и правил: метод декомпозиции, структурное программирование, метод проектирования программных средств, эталонное решение и другие, говорят о профессионализме.

Компьютер всегда прав

Самая раздражающая ситуация в программировании - когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка... ”. Возникает чувство, будто компьютер над вами издевается!

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

Успокойся и все получится

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

Самое сложное - начать

Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…» .
Просто начните . Начните с любого конца. Разбейте задачу на мелкие части и начните выполнять их. Перестаньте откладывать, отбросьте посторонние мысли, сконцентрируйтесь на задаче, и начните работу. Дальше пойдет как по маслу.

Читай книги

Читайте книги. Я еще раз напишу: Читайте книги!
Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь ”, “У меня нет времени ”, “Я читаю статьи в интернете ”. Это все здорово, но лично я считаю, что лучший источник знаний - это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме) , но я дойду, обязательно дойду.

Знай свои инструменты

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

Не будь перфекционистом

Выше я писал, что самое трудное - это начать. Так вот, закончить - тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод? ”, “Может это в отдельный класс? ”, “Было бы удобнее если бы... ”, “А вдруг потом понадобится... ”, “А вдруг... ”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым ”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.

Умей отдыхать

Самая большая проблема программистов в том, что мы любим свою работу. У меня в отпуске начинается ломка, неделя без программирования - и мне снится сон о том как я продумываю архитектуру нового приложения. Плюс программисту не сложно найти заказы на стороне, которыми можно заниматься по ночам. Плюс свои проекты. А сколько раз вы не могли уснуть, потому что мозг отказывался переключаться с задачи, которой вы занимались весь день?
Все это ведет к переутомлению, и, как правило, к снижению продуктивности. Отдохнувший программист - эффективный программист . Высыпайтесь. Найдите себе хобби, которое никак не связанно с мозговой деятельностью и посвящайте ему пару часов в день. Это позволит отвлечь мозг от работы, перезагрузить его. Самые интересные идеи и самые верные решения в последнее время приходят мне в голову в спорт-зале.