Шесть советов по написанию более понятного программного кода

[divbyzero]

Со всеми советами согласен, но больше всего меня подводил 5 пункт. Ибо нагородить всегда успеешь.

[obenjiro]

«Используйте оператор #define чаще. КАК МОЖНО ЧАЩЕ»
О_О Я вот наоборот читал что применение #define нужно снижать до «необходимого минимума» ибо иногда это приводит к недоразумениям. Пример:

define# MINUS 1 – 3
…
int x = 10 / MINUS ( = -3.333 а не -5 как ожидается)

По-моему так.

PS: Извините книгу не помню

[obenjiro]

Ой нет! Получиться -7 О_О

PS: Вот видите к каким недоразумениям это может привести :)

[divbyzero]

Нада просто понимать, что делаешь.
Например полезная конструкция при разработке: define('DEBUG', 1);

[Treg]

Тут как в поговорке - "научи дурака богу молиться...". Естесственно, ко всему надо подходить с умом и врядли будет оправдано дефайнить 1-3. Но основные параметры программы - те значения, с которыми часто приходится "играть", все же стоит обозначить дефайном. В таком ключе эта мера - более чем к месту.

[sysprg]

Это еще цветочки, гораздо хуже, если в параметрах есть выражение с автоинкрементом или еще что-то с побочным эффектом, а параметр подставлен в тело макроопределения пару раз, или когда приходится писать #define ...  do {...} while (0) чтобы свести все к одному оператору и не нарушить блочность программы - а забыв об этом получаешь феерические ошибки... В общем, чем МЕНЬШЕ в программе #define, тем лучше для читабельности и отладки, правда изредка страдает быстродействие.

[obenjiro]

Вот вот! Вы как будто книгу цитируете :)

[sysprg]

Современные компиляторы имеют настолько мощный механизм inline-подстановки, что кроме самых-самых тривиальных или критических к быстродействию случаев #define лучше не использовать. А в оригинале, НАВЕРНОЕ, имелось в виду, что лучше определять КОНСТАНТЫ через #define, чем писать их числами в коде. Но и тут тоже есть с чем поспорить. Ненавижу константы типа #define TEN 10 - как будто бы может быть иначе!

[obenjiro]

Немножко громкое заявление, но ощущение что #define - пережиток прошлого. ИМХО

[Ex3NDR]

их в шарпе упразднили... знаете константы удобнее) И код чидебельней становится

[seraph]

Вспоминается первоапрельская шутка, когда в рабочую версию проекта после предварительного бекапа в модуль определений включается что-то типа:
#define ("true","false")
За правильность когда не ручаюсь, ибо пользовался дефайнами достаточно давно, но идея, я думаю, понятна.

Вообще кроме включения отладки по мановению волшебной палочки реального применения дефайнам не вижу. А уж за реализацию «константа» вне классов путём обработки препроцессором скрипта разработчикам PHP надо отрывать руки, ИМХО.

[mactator]

define# MINUS (1 – 3)
и всё путем

ах, да: пункт 6 :)

[0re1]

То что вы задефайнили, то и получили.
Дефайнить надо коректно.

[SCode]

с первым согласен, всегда зыбваю что писал сам через месяц второй))

[sysprg]

1. Будьте благоразумны – пишите комментарии.

1. Комментарии должны пояснять действительно тонкие моменты. Так же приятно, когда откомментированы функции основных блоков кода, параметры процедур и ограничения на них. Но начитавшись о пользе комментариев, многие программисты начинают комментировать каждую строчку программы. Это бессмысленно, так как если в программе написано if (Counter ==  0) то и без банального комментария "проверяем счетчик на ноль" любому понятно, что делает этот if. Для кого пишут такие комментарии? И какой более емкий комментарий можно написать к такому if-у? Никакого? Так и не нужно тогда ничего писать!
2. Более того, обилие комментариев к каждой строчке в большинстве случаев даже вредно - так как на практике у любителей таких комментариев они быстро начинают расходиться с реальностью. Пример: if (Counter ==  0 ||  Counter >  Limit)  /*  проверяем счетчик на ноль */
3. Я не призываю вообще убрать комментарии, но оставить их только к более и менее крупным блокам кода и функциям в целом. Построчные - только к нетривиальным местам в программе. В остальном коде умный и без комментариев разберется, а дураку и комментарии не помогут. "Лишние" комментарии не мешают, конечно же, если не расходятся с реальностью, но и пользы от них никакой. Только съедают время на свою поддержку при модификациях.

[azizoid]

Ваш первый пункт можно отнести к 6 пункту автора...

[obenjiro]

Честно мне кажется 6 советами тут не отделаешься! Я читал книгу (об этом я говорил выше) которая полностью просвещенна КАК надо писать код. Причем книга написана не графоманом. А реально по делу и коротко и все равно 400 страниц.

Он писал о том, КАК комментировать, что комментировать, зачем. Как тестировать, как отлаживать, как писать код, чтобы потом отлаживать было удобней. Как тестировать. И так далее. В общем, слишком много важных вещей чтобы описать все в 6 советах. ИМХО

[sysprg]

5. «Преждевременная оптимизация – корень всех зол», – Дональд Кнут (Donald Knuth).

Автор цитаты - Хоар, а не Кнут. Кроме того, чтобы понять истинный смысл этой фразы, нужно сначала достичь своего предела в грязных извращенияхглубокой оптимизации кода, а затем уже остановиться и по-другому посмотреть на мир. Если же Ваши правила прочитает начинающий программист и сразу станет руководствоваться ими, с самого начала избегая оптимизации, то он никогда не станет гуру. И вообще непонятно тогда, зачем он на "C" пишет.

[1amer]

ещё нужно отметить то что не нужно лениться и код хорошо форматировать(хотя это наверно тока новички таким грешат).
и ещё Крис както писал(хотя и не он это придумал) про использование кодов ошибок типа 0xDEADBEEF для удобной отладки без надобности заглядывать в исходные тексты

[Muxa]

По поводу правильного написания кода очень рекомендую "Макконнелл. Совершенный код" (http://www.ozon.ru/context/detail/id/3159814/)
Прочитал от корки до корки и не пожалел ни на секунду

[seraph]

Угу. Книга из серии Must read для любого программиста.

[Nilf]

Пункт 2 - автор просто призывает избегать магических чисел.

[0re1]

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

Дефайн тож очень полезный прием, чаще всего дефайню for:

#define forn(i, n) for(int i = 0; i < int(n); ++i)
#define forv(i, a) forn(i, a.size())

и пары:
#define mp(a, b) make_pair((a), (b))